"XPNET 3.1 Interim Bug Fixes (IBFs) and Enhancements - XPNET" SCR # Change Description ----- ------------------ SCR #3261 NCPCOM - rel3^ver1^ncpc07^050926 26-SEP-05 - rel3^ver1^ncpl07^050926 SVNCS - rel3^ver1^sncs07^050926 - rel3^ver1^ncpl07^050926 BASE - rel3^ver1^base^rel08^20050926 rel3^ver1^sys07^050926 NCPDC - $data01.S31ncpi.ncpi05c NCPDCB74 - $data01.S31ncpi.ncpi05v NCPDCOB - $data01.S31ncpi.ncpi05x NCPDDDL - $data01.S31ncpi.ncpi05s NCPDFUP - $data01.S31ncpi.ncpi05z NCPDTAL - $data01.S31ncpi.ncpi05t NCPDTCL - $data01.S31ncpi.ncpi05a Reference: Internal Symptom: INFO LINE fails with the following response 1. INFO LINE fails with the following responseng "getversion failed, invalid Nodename." when using any LINE "keyword" attribute modifier, i.e. INFO LINE *,MODE. 2. BCS and ERIC do not appear as valid ete protocols when parsing the INFO LINE,ETE command. However, a BCS or ERIC line will be returned when specifying the NONE ETE. Also, when using NONE, line objects are returned that have an ETE value of zero but may notme. be valid ETE objects, i.e. CBIPP. Problem: 1. Case statement contained an error for the ete protocol case causing the keywordlist variable to have an invalid value. 2. X21 and OSI ete protocols were not included with INFO LINE ETE attribute command. Change: 1. Corrected the CASE statement for the ete attribute modifier. 2. Added the X21 and OSI ete protocols to the parsing routines and corrected the filter matching for ETE to include checking for valid ETE protocols. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Install the new BASE object file and rebind the network. Dependencies: XPNET 3.1 only. SCR #3267 SVIPF - rel3-ver0-ipf01-051007 07-OCT-05 rel3-ver1-ipf01-051007 Reference: Case 394086 Reference: Enhancement Symptom: A user is not allowed to use both lower and upper-case alpha characters in the IPF card type. Problem: None. Change: Modified SVIPF to read in a new server parameter. Valid values for the new UPSHIFT-CARD-TYPE parameter are "Y" and "N". If the UPSHIFT-CARD-TYPE parameter is set to "Y" (default value) all entered IPF card type values will be upshifted. Example: "aA" entered -> "AA" written to IPF. If the UPSHIFT-CARD-TYPE parameter is set to "N" all entered IPF card types will be written to the IPF file as entered at the screen (no UPSHIFT will occur). Example: "aA" entered -> "aA" written to IPF. If the UPSHIFT-CARD-TYPE parameter is missing or an invalid value is used (not "Y" / not "N") all card types will be upshifted by default (same as logic prior to this enhancement). Please note - no action or configuration change is required unless your site wishes to allow both upper and lower case characters in the IPF card type. Implementation: 1. Install the new SVIPF on the XPNET subvolume. 2. Freeze, Stop, Stop the SVIPF. 3. If the site wishes to enable this enhancement, one of the following PATHCOM commands should be entered: ALTER SERVER-PRE, PARAM UPSHIFT-CARD-TYPE "Y" or ALTER SERVER-PRE, PARAM UPSHIFT-CARD-TYPE "N" The above change should also be done to the PATHCONF. 4. Thaw the SVIPF. Dependencies: None. SCR #3265 SKELB - rel3^ver1^sutl05^20051003 10-OCT-05 SKELLIST SKELB - rel3^ver0^sutl24^051010 SKELLIST Reference: Case #401388 Symptom: EBT transactions getting treated as Mastercard resulting in declines. Problem: Due to invalid/obsolete requirements RPE 050315-01 SCR 3241 was added to identify new Diners Club card prefixes as a Mastercard routing method. In addition to the current logic of any card number with a prefix in the range "51" through "55" used to identify Mastercard, new logic to identify any card number with a prefix of "5" and a PAN length of 16 as a Mastercard routing method was added. This was added as a result of Mastercard Global Operations Bulletin No.12 Dated 1 December 2004 "Diners Club cards currently issued within the US and Canada are being reissued as Mastercard cards. These reissued cards: Have a 16-digit account number beginning with "5". Mastercard has since changed their position. Diner's Club cards reissued as Mastercards are no longer specified to be 16-digit PANs beginning with '5'. They are now specified to fall in the following ranges: 552817 - 552819 552822 552824 - 552828 552830 552832 - 552838 552840 - 552842 558898 Our original routing logic already identifies cards with a prefix of "55" as Mastercard so SCR3241 was not necessary. Change: Removed the logic added by SCR3241 to identify cards with a prefix of "5" and a PAN length of 16 as a Mastercard routing method. The original logic remains, any prefix in the range "51" through "55" will be identified as Mastercard. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3266 SKELB - rel3^ver1^sutl05^20051003 03-OCT-05 SKELLIST Reference: Clarify Case #401538 Symptom: Processes calling NETABEND are not producing ZZSA saveabend files. Problem: The call to ABEND in NETABEND was changed to a call to PROCESS_STOP_ with the option of a normal stop instead of abending. Change: Corrected the code (and comments) in NETABEND to perform ABEND logic. Also, fixed call of PROCESS_STOP_ in NETBLOCKWRITE to use ABEND logic. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3268 SKELB - rel3^ver1^sutl05^20051003 10-OCT-05 SKELLIST SKELB - rel3^ver0^sutl24^051010 SKELLIST Reference: RPE 050708-01 Symptom: N/A. Problem: Due to incomplete requirements for RPE 050708-01, SCR 3253 was added to identify a new BIN range "650000" to "650999" for Discover, however, there where additional changes required for more new ranges as well as refining the existing logic to remove some previously valid ranges. Prior to this SCR and SCR 3253 the valid ranges where: "601100" - "601109" "601120" - "601199" Current logic including this SCR and SCR 3253 is as follows: "601100" - "601109" "601120" - "601149" "6011740" - "6011749" "601177" - "601179" "601186" - "601199" "650000" - "650999" Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3275 SVNCPI - rel3^ver0^rel33^051101 (For XPNET 3.0) 01-NOV-05 - rel3^ver0^ut04^051101 - rel3^ver1^rel08^051101 (For XPNET 3.1) - rel3^ver1^ut01^20051101 Reference: Clarify case #402176 Symptom: ALTER STA/PRO, SERVICE command fails when the value for the service names equals 32 bytes. Problem: Service string length was not being properly calculated. Change: Corrected utility proc which is used for string length calculation. Implementation: Install new SVNCPI object file. Edit the pathconf and add or change SET SERVER HIGHPIN ON for each server-ncpi-?? definition. If on a RISC machine, accelerate the SVNCPI object as shown in the XPNET.NETAXCL file. Stop all the NCPI servers from TACL. Shutdown the pathway system and obey PATHCOLD. Dependencies: None. SCR #3269 TCPCLI - rel3_ver0_tcpc27_050920 12-OCT-05 rel3_ver0_tcpl20_050920 rel3_ver0_ctse15_051006 TCPSRV - rel3_ver0_tcps31_050920 rel3_ver0_tcpl20_050920 rel3_ver0_ctse15_051006 CTSE - rel3_ver0_ctse15_051006 CTS - rel3^ver0^cts27^051012 CTSDC - $data01.n30cts.cts05dc CTSDDDL - $data01.n30cts.cts05ds CTSDTAL - $data01.n30cts.cts05dt CTSDTCL - $data01.n30cts.cts05da NETETCL - n30ems.ems25ea NETEC - n30ems.ems25ec NETEDDL - n30ems.ems25es NETETAL - n30ems.ems25et NETECOB - n30ems.ems25ex NETTPLO - n30ems.ems30po NETTPLS - n30ems.ems30ps * * XPNET 3.1 * CTSE - rel3_ver1_ctse02_051025 CTS - rel3_ver1_cts02_20050806 CTSDC - $data01.n31cts.cts03dc CTSDDDL - $data01.n31cts.cts03ds CTSDTAL - $data01.n31cts.cts03dt CTSDTCL - $data01.n31cts.cts03da NETETCL - n31ems.ems05ea NETEC - n31ems.ems05ec NETEDDL - n31ems.ems05es NETETAL - n31ems.ems05et NETECOB - n31ems.ems05ex NETTPLO - n31ems.ems05po NETTPLS - n31ems.ems05ps Reference: Case 400719 Symptom: None. Problem: Customer needs Little Endian format for the length field and TCPCLI and TCPSRV didn't support it. Change: Modified to handle Little Endian format for the length field. Modification allows for 2 byte length field in binary format only. To specify this format, the userdata for the station must contain -L+. The default is -L-. Dependencies: None. SCR #3270 CTS - rel3^ver0^cts27^051012 13-OCT-05 CTS - rel3_ver1_cts02_20050806 Reference: Internal. Symptom: On a TCPCLI/TCPSRV backup takeover, XPNET experiences error 17 when it tries to re-open CTS lines and they go ABNORMAL. The following log message is generated: File \K9.$DSRV, open error 17 (17) Problem: SCR3246 modified TCPCLI/TCPSRV to reply with error 17 to any system message it receives before receiving the cpu down system message. There are times when they receive an open system message from XPNET before receiving the cpu down message. XPNET was not expecting an error 17 so the line went ABNORMAL. Change: Modified XPNET to retry the open if it received an error 17. Dependencies: None. SCR #3259 BASE - rel3^ver0^rel65^050714 30-AUG-05 - rel3^ver0^oncf^lnk06^050713 - rel3^ver0^oncf^pro09^050713 BASE - rel3^ver1^base^rel09^20051111 - rel3^ver1^oncf^lnk02^20050830 - rel3^ver1^oncf^pro07^20050830 Reference: Case #396690 Symptom: XPNET abnormally terminates with code 6517 during a warmbackup takeover. Problem: The XPNET warmbackup takeover logic calls NSK procedure PROCESS_GETPAIRINFO_ using PPD names from the NEF to determine which processes are still running and need to be stopped. If the PPD name has been fully qualified with a system name, (i.e. \SYS1.$AUTH) the internal format of this name is stored in the NEF (i.e. "\n AUTH" - where n is the system number for \SYS1). The PPD name is upshifted when it is read from the NEF and if the system number happens to be in the range of a lower case ASCII letter (decimal 97 "a" through 122 "z") the system number gets upshifted to an invalid/non existent system number (decimal 41 "A" through 90 "Z"). When a ppd name with an invalid system number is passed to PROCESS_GETPAIRINFO_, it returns an error 2. This error causes XPNET to dump with a 6517. Change: Added logic to examine the PPD name before upshifting it. If the PPD name is in internal format, then the first two characters are not upshifted. Implementation: Install the new BASE object file and rebuild the network using the NETB file. If you have XPNET 3.0 installed and you are on a RISC machine, accelerate the objects as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3276 BASE - rel3^ver0^rel65^050714 02-NOV-05 rel3^ver0^proc36^051102 BASE - rel3^ver1^base^rel09^20051111 rel3^ver1^proc05^20051102 Reference: Case 402900 Symptom: The Tandem system number on the machine XPNET 3.1 is running on is in the range of decimal 97 to 122 (this equates to lowercase ascii "a" to lowercase ascii "z"). Starting a link/satellite process causes the node to abend. NOTE: Please refer to the explain file for SCR 3259 to see the issue with the Tandem system number being in the previously mentioned range. Problem: Each process (link and satellite) have a PPD name and the Tandem node name associated with them. When they are started, if the PPD name is fully qualified with the system name, XPNET verifies that the system number associated with the PPD name equals the system number associated with the Tandem node name. If they aren't equal, XPNET modifies the PPD name to match the Tandem node name. When it does, it overwrites other data fields making them invalid and XPNET dumps. NOTE: This problem existed in XPNET 3.0 but because it is written in non-native code the stack positioned the variables in a way that the area walked on didn't affect processing. The problem was found in 3.1 because with native code the variables are positioned differently on the stack and were walked on. Change: Modified the code to not walk on the unintended area. Implementation: Install the new BASE object file and rebind the network. If on a RISC machine, accelerate the objects as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3277 BASE - rel3^ver1^base^rel09^20051111 11-NOV-05 rel3^ver1^dcom04^20051111 Reference: Clarify Case #403386 Symptom: STATION routing based upon RPC failing on first mismatch of a MATCHELEMENT in a MATCHGROUP. Problem: MATCHELEMENT processing not continuing through all entries. Change: Changed code to evaluate all MATCHELEMENT entries in a MATCHGROUP. Implementation: Install the new BASE object file and rebind the network. Accelerate the objects as shown in the XPNET.NETAXCL file. Dependencies: None. SCR SSL TCPCLI/SSLCLI - rel3_ver0_sslc00_051215 15-DEC-05 rel3_ver0_tcpc28_051215 rel3_ver0_tcpl21_051215 rel3_ver0_ctse16_051215 TCPSRV/SSLSRV - rel3_ver0_ssls00_051215 rel3_ver0_tcps32_051215 rel3_ver0_tcpl21_051215 rel3_ver0_ctse16_051215 TCPTPLO - $data01.n30tcpl.tcp05po CTSETPLO - $data01.n31ctse.ctse01po STGKM - Last Modified - 11NOV2005 9:22 ROOTCERT - Last Modified - 19MAY2005 10:02 Reference: Internal/GA of SSL. Symptom: None. Problem: None. Change: Added functionality to handle SSL over a TCPIP connection. This enhancement uses the SafeTGate SSL Library. Added functionality for SSL to refresh the Licence file , Certfile and the Rootfile. The code will also look for the latest version of the configuration file to use when refreshing and when starting. The version processing will require the config file to be in the following form xxYYMMDD. Implementation: Move in the new SSLSRV, SSLCLI and CTSE modules. Stop any of the associated stations. Stop and re-start SSLSRV and/or SSLCLI. Re-start the previously stopped stations. See implementation guide. Dependencies: XP 3.0 - Requires *** CTS27 *** due to scr3246. XP 3.1 - Requires *** CTS02 *** due to scr3246. SCR #3281 RELPROC - ver NOV2005, file u31relp.relp01as 22-NOV-05 Reference: Internal Symptom: RELPROC produces garbled output in 2 different cases for TNS objects (file code 100): (1) When the NonStop system DST (daylight savings time) table has an inadequate number of entries for some older timestamps the BIND LIST CODE REL command output would not display a compilation timestamp and would cause RELPROC to display invalid output. (2) RELPROC would not display valid output for Vproc-type procedures in TNS objects. Problem: (1) RELPROC was not accounting for timestamp information to be missing in the BIND LIST CODE REL output. (2) Code was missing to correctly display Vproc-type procedures when present in TNS objects. Change: (1) Modified RELPROC to account for missing timestamp information in the BIND LIST CODE REL output. (2) Modified RELPROC to correctly display Vproc procedures when present in TNS objects. Implementation: Install the new RELPROC macro file on the XPNET subvolume. Dependencies: None. SCR #3288 NETCJRD - rel3^ver1^cjrp02^051212 12-DEC-05 - rel3^ver0^cjrp11^051212 Reference: Case #304490 Symptom: Program trapped if there were more than 99 files in the chain of CJ files being reported on. Problem: Program was not coded to handle more than the 99 files. Change: Increased the limit to 500. Also added logic to handle the situation once 500 files has been reached: the program will now report on the files it finds and will emit an error banner to the hometerm and as the first and as the last page of the spooled report. If this new limit is ever reached, the customer can still generate reports for all of his CJ files but must do so in 500 file increments. The program will report 500 files back from the initial file that's been passed in on the command line. i.e.: | v run netcjrd/out $s.#hold/ $vol.subvol.CJnnnnnn Implementation: Install new object file. Dependencies: None. SCR #3284 NETADRD - rel3^ver1^audr03^20051201 01-DEC-05 Reference: Internal Symptom: None. Problem: None. Change: Added the option to display audit data in a hexadecimal and ASCII format. When the HEXASCII option is specified (abbreviation is "HEXA"), the output will be displayed as 16 characters per output line with the hexadecimal value shown on the left and the corresponding ASCII representation shown on the right. Characters not representable as ASCII characters will be denoted on the right using the "." character. Note that the old HEX option can still be used. If HEX and HEXASCII are both used as options on the command line, the first option parsed will dictate the format of the output. The HEXASCII option will override other display options (such as ASCII, OCTAL, BYTE, etc.). Implementation: Install the new NETADRD object file on the XPNET subvolume. Dependencies: None. SCR #3285 NCPCOM - rel3^ver1^ncpc08^20051202 02-DEC-05 Reference: Case 404241 Symptom: When the NCPCOM PROMPT env variable is set to BOTH or NAME, the object name portion of the prompt may appear incorrectly after one of the following commands is performed: ASSUME NODE * ASSUME SYSNAME * Problem: The object name for the prompt was not getting displayed correctly in all cases. If the assumed object name was not a node or sysname and an ASSUME NODE * or ASSUME SYSNAME * command was performed, the default object name would still be shown in the object name area of the prompt. Change: Modified the prompt handling to not display the assumed object name (non-NODE and non-SYSNAME) if the assumed object type is NODE or SYSNAME. Implementation: Install the new NCPCOM object file on the XPNET subvolume. Exit from and restart any running NCPCOM user interfaces. Dependencies: None. SCR #3286 NCPCOM - rel3^ver1^ncpc08^20051202 02-DEC-05 Reference: Case 404240 Symptom: An extra space is inserted before the command number in the 3.1 NCPCOM prompt. This does not match how the 3.0 NCPCOM works. Problem: Changes made for 3.1 NCPCOM prompt enhancements caused an extra space to be inserted in from of the command number. Change: Modified the prompt handling so that the extra space is not displayed. Implementation: Install the new NCPCOM object file on the XPNET subvolume. Exit from and restart any running NCPCOM user interfaces. Dependencies: None. SCR #3287 BASE - rel3^ver1^base^rel10^20051130 08-DEC-05 - rel3^ver1^oncf^sys08^20051130 Reference: Internal case 404436 Symptom: Attributing filtering of DEST objects does not work for most of the DEST attributes. Problem: When processing the filter request, the XPNET code was not locating the DEST object NEF record in memory so that the attribute filter value could be compared against the attribute value configured in the object. Change: Modified the code to locate the DEST object NEF record in memory before attempting the comparison of the attribute filter value. Implementation: Install the new BASE object file on the XPNET subvolume. Rebuild the network object using the NETB file. Dependencies: None. SCR #3289 BASE - rel3^ver1^base^rel10^20051130 09-DEC-05 - rel3^ver1^gate05^20051209 Reference: Internal case 404500 Symptom: Node traps with signal 26 (loop-timeout) when adding a process object to the NEF for a destination that was previously a service with external providers. Stack trace looks like this: 0 TAL #DLIB_NM_TRAP_HANDLER.#953(DLIB05TS) + %HAI Unknown TNS/R Code Space %h7C354790 1 TAL #TREE^LOCATE.#887(TREE02TS) + %H9I 2 TAL #DEST^LOCATE.#14561(GATE04TS) + %H4I 3 TAL #DEST^FIND.#5264(GATE04TS) + %H8I 4 TAL #DEST^PRO^SERVICE^QUEUE^COUNT.#16025(GATE04TS) + %H4I 5 TAL #PROCESS^OUTPUT^TASK.BUILDBLOCK.#11042(PROC05TS) + %H6I ... 11 TAL #DEST^ADD^OBJECT.#4428(GATE04TS) + %H8I 12 TAL #DEST^ADD.#3909(GATE04TS) + %H8I 13 TAL #ADD^PROCESS.#5314(EXEC05TS) + %H7I 14 TAL #ONCF^PROCESS.EXECUTE^ADD^CMD.#1951(PRO07TS) + %HDI ... 22 TAL #REL3^VER1^EXEC05^20050519.#4283(EXEC05TS) Problem: When the node was transitioning the service to a process, some of the code used to check service queue counts did not take into account that a service dest could be transitioning/adapting into a local process (or station). Change: Modified the code to check for service dests that have changed type when checking service queue counts. Implementation: Install the new BASE object file on the XPNET subvolume. Rebuild the network object using the NETB file. Dependencies: None. SCR #3290 BASE - rel3^ver1^base^rel10^20051130 12-DEC-05 rel3^ver1^oncf^sys08^20051130 NCPCOM - rel3^ver1^ncpc08^20051202 rel3^ver1^ncpl08^20051128 SVNCS - rel3^ver1^sncs08^20051212 rel3^ver1^ncpl08^20051128 SVNCPI - rel3^ver1^rel08^20051130 rel3^ver1^ncp09^20051130 NCPDTCL $data01.s31ncpi.ncpi06da NCPDC $data01.s31ncpi.ncpi06dc NCPDDDL $data01.s31ncpi.ncpi06ds NCPDTAL $data01.s31ncpi.ncpi06dt NCPDCB74 $data01.s31ncpi.ncpi06dv NCPDCOB $data01.s31ncpi.ncpi06dx NCPDFUP $data01.s31ncpi.ncpi06dz Reference: Internal Symptom: None. Problem: STATUS command enhancement. Change: Added the attribute filter to the STATUS, STATISTICS, RESETSTATS, START, STOP and ABORT commands for all objects with the following exceptions: ABORT NODE START NODE STOP NODE Added a new CONNECTED filter for the LINE and STATION objects. CONNECTED and NOT CONNECTED are the variations of the filter allowed. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Stop all the NCPI servers from TACL. Install the new BASE object file and rebuild the network using the NETB file. Dependencies: XPNET 3.1. SCR #3291 NCPCOM - rel3^ver1^ncpc08^20051202 12-DEC-05 Reference: Case #404505 Symptom: INFO command with an attribute filter has missing header and detail in the response when entering a new command at the MORE prompt. Problem: Attribute filter flag not being properly reset after MORE flag processing. Change: Reset the attribute filter flag when a new command is entered at the MORE prompt. Implementation: Install new files on the XPNET subvolume. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1. SCR #3292 NCPCOM - rel3^ver1^ncpc08^20051202 12-DEC-05 rel3^ver1^ncpl08^20051128 SVNCS - rel3^ver1^sncs08^20051212 rel3^ver1^ncpl08^20051128 Reference: Case #404503 Symptom: After altering any AVAIL event attribute and then doing an INFO,EVTINFO command, it appears that both the AVAIL and CONFIG event attributes have been altered. Problem: The CONFIG event attribute is displaying the AVAIL event attribute. Change: Changed the display routines to use the correct attribute for the CONFIG event display field. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1. SCR #3293 SVNCS - rel3^ver1^sncs08^20051212 12-DEC-05 NCPCOM - rel3^ver1^ncpc08^20051202 Reference: Case #404499 Symptom: SVNCS loops when executing an obey file with SHOW DEST command. Problem: DESTOBJ was not allowed for in the SHOW proc so the present^entry value was being set based on the OTHERWISE condition which was incorrect in that it didn't update the TCB.present^entry thus causing the while loop to execute indefinitely. Change: Added DESTOBJ to the case statement and corrected the OTHERWISE condition to update the TCB.present^entry. Also, added DESTOBJ to the case statement in NCPCOM for consistency even though it was not causing a problem. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1. SCR #3296 SVNCPI - rel3^ver1^rel09^20051130 21-DEC-05 - rel3^ver1^ncp08^20051130 Reference: Case #405027 Symptom: NCPCOM or NCS gives a response indicating invalid context when performing a command using a wild-carded object name. Other symptoms are possible, up to and including an abend of a SVNCPI process. Problem: Code added to SVNCPI for the XPNET 3.1 DEST objects introduced a bug in how an ADD STATION command is processed. Memory may be written over during these types of commands. Change: Modified the code to correctly update the internal station object in the object table when processing an ADD STATION command response from XPNET. Implementation: Install the new SVNCPI object. STOP both the primary and backup SVNCPI PPD's from TACL. Dependencies: None. SCR #3297 SVNCPI - rel3^ver1^rel10^20060103 04-JAN-06 rel3^ver1^evt01^20060103 rel3^ver1^rn04^20060103 NCPETCL - $data01.s31ncpi.ncpi01ea NCPEDDL - $data01.s31ncpi.ncpi01es NCPETAL - $data01.s31ncpi.ncpi01et NCPTPLS - $data01.s31ncpi.ncpi01ps NCPTPLO - $data01.s31ncpi.ncpi01po Reference: Internal Symptom: SERVER-NCPI abends at startup during conversion of XPNET to version 3.1. A saveabend is created showing programmatic trap 1000 called from RN^POP^CONS. Problem: This abend is generally caused by SERVER-NCPI reading the NEF file for the previous release. The NEF records from the previous release are not compatible with the current release. This could cause multiple, unnecessary saveabend files being created. Change: Modified the code so that a saveabend file is not created. Rather, when a NEF of invalid record length is read, SERVER-NCPI will log a new EMS event, number 52, to indicate the problem: SERVER-NCPI event 52 (logged with emphasis on): "NCPI fatal error. NEF <1> has invalid record "length for this NCPI." parameter <1> = filename of the NEF that was opened After this event is logged, the SERVER-NCPI process will stop itself without creating a saveabend file. Implementation: Install the new SVNCPI object. STOP both the primary and backup SVNCPI PPD's from TACL. Re-install all EMS templates using the SCRIBE.GOINST macro. Dependencies: None. SCR #3299 SVNCPI - rel3^ver1^rel10^20060103 04-JAN-06 rel3^ver1^ncp09^20060103 rel3^ver1^obj07^20060103 rel3^ver1^rn04^20060103 NCPCOM - rel3^ver1^ncpc09^20060110 rel3^ver1^ncpl09^20060110 SVNCS - rel3^ver1^sncs09^20060110 rel3^ver1^ncpl09^20060110 Reference: Internal case 405500 Symptom: Doing any DEST command with a filter (e.g. INFO DEST *, ADDED or STATUS DEST *, QUEUE) caused the "int table invalid" error to be returned to NCPCOM/NCS. This error indicates the node thinks that for some reason its internal tables are out of sync with the object information held in SERVER-NCPI. Problem: SVNCPI was not checking for dests corresponding to disabled processes and lines/stations when formatting and sending filter requests to the XPNET process. Change: Modified SVNCPI to make appropriate checks for corresponding disabled process and line/station entries when performing various DEST object commands. Implementation: Install new files on the XPNET subvolume. STOP both the primary and backup SVNCPI PPD's from TACL. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: None. SCR #3300 NCPCOM - rel3^ver1^ncpc09^20060110 10-JAN-06 rel3^ver1^ncpl09^20060110 SVNCS - rel3^ver1^sncs09^20060110 rel3^ver1^ncpl09^20060110 Reference: RPE 051228-11 Symptom: NCPCOM batch command enhancement. Problem: Customer request to suppress the MORE prompt in NCPCOM so output can be captured and used by some other tool. Change: Created a new environment attribute called the MORE PROMPT that can be set to suppress the MORE prompt. The new command is SET MORE ON|OFF ( The default is on.) The ENV command is changed to reflect the value of the new attribute. MORE PROMPT ON or MORE PROMPT OFF Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1 only. SCR #3301 NCPCOM - rel3^ver1^ncpc09^20060110 10-JAN-06 rel3^ver1^ncpl09^20060110 SVNCS - rel3^ver1^sncs09^20060110 rel3^ver1^ncpl09^20060110 Reference: Case 405241 Symptom: EMS event for audited ONCF commands with an attribute filter are not formatted correctly. Problem: The attribute filter being passed to the EMS filter contains all filters entered not just the attribute filter. This causes some filters to appear twice in the EMS event. Change: Changed the scan to terminate on a comma to correctly parse each filter and save off the correct command text. Also, upshifted the attribute name but not the filter criteria. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1 only. SCR #3302 NCPCOM - rel3^ver1^ncpc09^20060110 10-JAN-06 rel3^ver1^ncpl09^20060110 SVNCS - rel3^ver1^sncs09^20060110 rel3^ver1^ncpl09^20060110 Reference: Case 405242 Symptom: An ONCF command with the UNDER CLASS filter and the CLASS attribute filter yields "no obj met filter criteria." response when in fact objects do meet the filter criteria. Problem: Work area for CLASS was initialized to spaces for a length less than the length of the CLASS attribute. This would could leave garbage in the field and prevent a valid compare with match criteria. Change: Corrected the move length when intializing the CLASS work area. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1 only. SCR #3304 NCPCOM - rel3^ver1^ncpc09^20060110 18-JAN-06 rel3^ver1^ncpl09^20060110 SVNCS - rel3^ver1^sncs09^20060110 rel3^ver1^ncpl09^20060110 Reference: Case 406228 Symptom: Help syntax for RESETSTATS command is missing the COUNTERS and MAXQUEUE modifiers. When these modifiers are used they will work; however, a syntax error occurs when used with another filter unless the COUNTERS or MAXQUEUE modifier is listed first. Problem: When the RESETSTATS command was modified by scr #3290, part of the filter processing was moved from NCPCOM/SVNCS to NCPLIB. An incorrect RESETSTATS parsing list was used in NCPLIB which which allowed the command to work but left out the modifiers in the help syntax. This also introduced the problem with the order of the modifier with a filter. Change: Corrected the parsing list used with the command and removed all filter processing from NCPCOM/SVNCS to NCPLIB. This corrected the order problem and also made the RESETSTATS proc consistent with other commands, i.e. STATISTICS. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1 only. SCR #3278 NETDMPRD - rel3^ver1^dmqe02^20051111 11-NOV-05 rel3^ver0^dmqe03^060116 Reference: Internal Symptom: The text length of messages written to the audit file is incorrect in some cases. In these cases it is set to 0 or 8. Problem: Net Dump Read was attempting to set field msg^int^status to special values in certain cases, but was off by one because of changes to the queue header in 3.1. That caused it to set msg^length which is one word in front of msg^int^status. Change: Used $len of the queuheader and define msg^int^status to calculate the correct offset. Implementation: Install the new DMQE object file. Dependencies: None. SCR #3305 SKELB - rel3^ver0^sutl25^060123 23-JAN-06 rel3^ver1^sutl06^20060123 Reference: RPE 051109-01 Symptom: N/A. Problem: Updates to the valid BIN ranges allowed for Discover cards. Sixteen digit PANS within the following two ranges will be deemed Discover card prefixes: "60110000" - "60119999" or "650000" - "659999" Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3311 23-FEB-06 TCPTPLO - $data01.n30tcpl.tcp06po TCPTPLS - $data01.n30tcpl.tcp06ps CTSETPLO - $data01.n30ctse.ctse05po CTSETPLS - $data01.n30ctse.ctse05ps CTSETPLO - $data01.n31ctse.ctse01po CTSETPLS - $data01.n31ctse.ctse01ps Reference: Internal Symptom: SSL messages are not getting logged. No Text token messages are logged instead of the actual log message. Problem: Wrong version of TCPTPLS/O was released in SCR SSL. Change: Releasing the correct version of TCPTPLS/O. Implementation: Re-install all EMS templates using the SCRIBE.GOINST macro. Dependencies: None. SCR #3313 Files unique 08-MAR-06 for XPNET 3.0 Accelerates -------------- ----------------------- XPNET.ocaALL - u30oca.ocaA00as all TNS objects on subvol XPNET.ocaBUILD - u30oca.ocaB00as called by all OCA routines XPNET.ocaAPPL - u30alib.oca00as APPLIB XPNET.ocaNET - n30base.oca00as NETWORK XPNET.ocaNETAD - n30audr.oca00as NETADRD XPNET.ocaNCP - s30ncp.oca00as SVNCP XPNET.ocaNCPI - s30ncpi.oca00as SVNCPI XPNET.ocaNLIB - n30nlib.oca00as NLIB XPNET.ocaPREG - s30pre.oca00as PREGEN XPNET.ocaSKELB - n30sutl.oca00as SKELB XNLIB.ocaSMPL - u21smpl.oca00as (sample OCA file) XNLIB.ocaXNLIB - u30xlib.oca00as XNLIB Files unique for XPNET 3.1 Accelerates -------------- ----------------------- XPNET.ocaALL - u31oca.ocaA00as all TNS objects on subvol XPNET.ocaBUILD - u31oca.ocaB00as called by all OCA routines XPNET.ocaAPPL - u31alib.oca00as APPLIB XPNET.ocaNETAD - n31audr.oca00as NETADRD XPNET.ocaNCP - s31ncps.oca00as SVNCP XPNET.ocaNCPI - s31ncpi.oca00as SVNCPI XPNET.ocaNLIB - n31nlib.oca00as NLIB XPNET.ocaPREG - s31pre.oca00as PREGEN XPNET.ocaSKELB - n31sutl.oca00as SKELB XNLIB.ocaSMPL - u31smpl.oca00as (sample OCA file) XNLIB.ocaXNLIB - u31xlib.oca00as XNLIB Files for XPNET 3.0 & 3.1 Accelerates --------------- ----------------------- XPNET.ocaAUDP - u30audp.oca00as AUDPRO XPNET.ocaPATH - n21path.oca00as PATH XPNET.ocaPWR - n21pwr.oca00as PWR XPNET.ocaPWS - n30pws.oca00as PWS XPNET.ocaQFI - n30qfi.oca00as QFI XPNET.ocaQFILD - n30qfi.ocal00as QFILOAD XPNET.ocaTCPC - n30tcpc.oca00as TCPCLI XPNET.ocaTCPS - n30tcps.oca00as TCPSRV XPNET.ocaUDP - n30udp.oca00as UDP SCRIBE.ocaEMSP - n30empp.oca00as EMSPERUS Reference: Internal, case 408953 Symptom: None. Problem: None. Change: Developed TACL routine files which can be used by customers to accelerate TNS objects for Itanium machines using the HP Object Code Accelerator (OCA) utility. See the list of files above, with the respective name of the object(s) they accelerate. Implementation: Install the new files on the XPNET, XNLIB and SCRIBE subvols as indicated. To OCA-accelerate objects on the XPNET subvolume, the OCAALL file can be run to accelerate all the objects it can find (required and optional) on the XPNET subvolume or each individual object can be accelerated separately using its respective OCA file. Note that OCAALL first performs a checklist of the files it can accelerate and then invokes the respective individual OCA files, as necessary, to OCA-accelerate each module. On the SCRIBE subvolume, run the OCAEMSP file to accelerate the EMSPERUS object. If the XNLIB object is used, run the OCAXNLIB file on the XNLIB subvolume to accelerate the XNLIB object. The OCASMPL TACL routine file can be used for accelerating TNS user applications which use the XNLIB run-time library. Just FUP DUP OCASMPL to the location of the object that you want to accelerate, modify the DUP'ed macro file to point it to the correct object file and create the correct target file and then run it from the TACL prompt. You can add options to suppress warnings as necessary. The TACL routines are designed to create a new object of the same name with an "A" appended to the end of the object filename (e.g. when the SVNCPI object is accelerated, a SVNCPIA accelerated object is created). If the OCA acceleration is successful, the original object is named to a ZZOCnnnn file and the "A" file is renamed to the original object file. You can purge the ZZOCnnnn file that was created as procedures warrant. Stop and restart the object if necessary. The HP OCA utility is available with the H-series NonStop OS for Itanium machines. Note also that the HP OCA utility is available with the G-series NonStop OS starting with G06.27. OCA accelerating an object on a non-Itanium system does not modify the performance of the object on that system, but does allow the object to run with optimal performance once it is moved to an Itanium system. Dependencies: None. SCR #3308 SKELB - rel3^ver1^sutl07^20060220 20-FEB-06 SKELLIST - sutl07tl OCASKELB - n31sutl.oca01as SKELB - rel3^ver0^sutl26^060220 SKELLIST - sutl26tl OCASKELB - n30sutl.oca01as Reference: Case 404177 Symptom: A SKEL-based satellite calls LOG^MESSAGE^ to log a message received from a device, but the message is truncated by the SKEL logging routines. The text "*** TRUNCATED ***" is displayed at the end of the truncated message. Problem: The SKEL library was only designed to log a maximum of 512 bytes of application text (after template formatting). However, that number is reduced by other formatting that the SKEL logging routines add to the event, bringing the total amount that can be logged by the application (after formatting) to 406 bytes before truncation of the message is invoked. The code was working as designed, but it has been decided to expand the amount of text which can be logged by a SKEL-based application to avoid unnecessary truncation of application events. Change: Modified the SKEL library to use extended memory buffers when formatting events to be logged. This reduces the stack requirements of the SKEL logging routines and allows events of 2800 bytes of application text to be sent to an EMS collector and logged to the EMS event log file. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. If on a TNS/E (Itanium) machine, accelerate the SKELB using the OCASKELB TACL routine provided. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3320 BASE - rel3^ver1^nstp02^20060420 20-APR-06 - rel3^ver1^base^rel11^20060421 Reference: Case #411379 Symptom: Checkpoint error 30 results in XPNET disabling its backup. Problem: XPNET disabled its backup when a Guardian error 30 was received as a result of a CHECKPOINTMANYX or FILE_OPEN_CHKPT_ proc call. The Guardian error 30 was returned as a result of the maximum number of RECV message blocks being reached in the backup. This problem was fixed previously (see SCR2766), but was reintroduced due to some changes required for PTAL. The call to procedure INITIALIZER was moved, however the calls to CONTROLMESSAGESYSTEM were not. Change: Moved the calls to CONTROLMESSAGESYSTEM back in front of the call to INITIALIZER in FES^INIT. This once again prevents the XPNET BACKUP from having the default of 255 message blocks which will alleviate the error 30. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: XPNET 3.1 only. SCR #3324 NCPCOM - rel3^ver1^ncpc10^20060425 10-MAY-06 NCPCOM - rel3^ver0^ncpc38^030706 NCPCBLD - $data01.u10ncpc.ncpc00as NCPCOMB - $data01.u10ncpc.ncpc00b NCPCOMBC - $data01.u10ncpc.ncpc00bc NCPCSEC - rel1^ver0^ncpcsec00^20060515 NCPCUPDT - rel1^ver0^ncpcupdt00^20060515 Reference: WO 060306-01 Symptom: Sarbanes-Oxley (SOX) requirements. Problem: N/A Change: Enhanced the NCPCOM module to allow the inclusion of the standard UPDTLIB logic and code block used by the modules on the XN30B24 subvol today. This logic and code block are used to include an encrypted userid and password in the object file. In this way, generic user IDs for automated operations environments can still control the system without the need for user/password information to be supplied within batch input files. Access to this object would be controlled using Guardian/Safeguard security. NCPCOM checks for the presence of the UPDTLIB (NCPCSEC) logic. If this is not present, then a SET USER/LOGON command with a password will need to be done to set the security information in the request; just as it is done today with the standard NCPCOM utility. If NCPCSEC has been bound into the specific updated NCPCOM object, then this security information applies on all requests. SET USER/LOGON commands from the prompt/command-line will be ignored, the SET PASSWORD command will be rejected with an error. A new TACL macro (NCPCBLD) will be used to build an NCPCOM object (NCPCOMX) with the NCPCSEC logic and prompt for a USERID and PASSWORD to encrypt into this new NCPCOMX object. If different USERID/PASSWORD combinations are required this macro will have to be run multiple times and the NCPCOMX object file created will have to be renamed or duplicated before creating and updating the next object. Implementation: Install new files on the XPNET subvol. Execute the NCPCBLD Macro to build the NCPCOMX object and update the ONCF userid and password. NCPCBLD Do you wish to build NCPCOMX file? (Y or N)y BIND/IN NCPCOMB, OUT $S.#NCPSEC/ This TACL routine updates the NCPCOMX object file with a user name and password for ONCF security. The Guardian user executing this routine must have write access to the code files on this subvolume. Searching for files to update for ONCF security... NCPCOMX Mod: 5/11/2006 9:59:10 "CCCC" 154,172 Do you wish to update this file? (Y or N)y Please enter the user ID:super/oper Please enter the password: Updating NCPCOMX... Code file $SYSACI.XPNET.NCPCOMX has been updated Dependencies: None. SCR #3325 SVNCPI - rel3^ver0^rel34^060127 15-MAY-06 - rel3^ver0^rn19^060127 SVNCPI - rel3^ver1^rel11^20060127 - rel3^ver1^rn05^20060127 Reference: Case #406546 Symptom: Valid alternate collector specified in NEF not being used by XPNET. Problem: The alternate collector name is passed as an ASSIGN from SVNCPI after it PROCESS_CREATE's the XPNET node. The value in the NEF was not being moved into the variable in NCPI's memory causing garbage to be passed. When the XPNET node attempted to open this, it failed and switched the alternate collector to $0. Change: Corrected the logic in NCPI to properly pass the alternate log assign to XPNET at initialization. Implementation: Install new SVNCPI module and stop all NCPI server processes from TACL. Dependencies: None. SCR #3309 NETDMPRD - REL3^VER1^DMQE03^20060123 23-JAN-06 NETDMPLB - eof 139024, date 25APR2006 5:21 Reference: Internally Generated Symptom: NETDMPRD truncates counters on the report output if the counter is larger than 5 digits. Problem: Report output allowed a maximum of five digits for message counters. Change: Expanded the report format to allow up to a ten digit counter. Altered the report output to left blank fill message counters. Implementation: Install the new NETDMPRD object file. MIPS PLATFORM NOTE: Mips customers will receive a new user library file named NETDMPLB. This user library is required for NETDMPRD beginning with this version. Install the new NETDMPLB and specify it in the "lib" statement when running NETDMPRD. This user library is not needed, and is not released, for the Itanium platform. See the "NET24-XPNET Network Control Operations Guide" dated May 2006 or later for details. Dependencies: None. SCR #3322 BASE - rel3^ver1^exec06^20060123 05-MAY-06 - rel3^ver1^nstp03^20060123 - rel3^ver1^base^rel12^20060123 Reference: Internal Symptom: The number of multiple message checkpoints shown in NODE STATISTICS were constantly increasing while no message traffic was occurring. XPNET node dumped with a 6520 when a takeover occurs. Problem: When an incomplete checkpoint occurs, the new primary XPNET dumps because it knows its memory is in an inconsistent state. The internal trace table used to capture all activity through XPNET's main loop was updated on each AWAITIOX time-out. However, a checkpoint is not performed until an I/O or timer/dispatch item completes. So while no activity is happening a large number of entries in the trace table were being updated and marked to be checkpointed. When the checkpoint was done, the amount of data in trace table that had changed while the XPNET node was idle caused the checkpoint size to overflow the max checkpoint size of 50000 bytes which results in a multiple message checkpoint. Change: Changed the logic to not checkpoint the internal trace table. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: None. SCR #3323 BASE - rel3^ver1^nstp03^20060123 05-MAY-06 - rel3^ver1^base^rel12^20060123 GLOBAL - n31glbl.glbl07 Reference: Internal Symptom: Event number 7031 (Backup stopped) logs and the XPNET backup process stops. Problem: The size of the checkpoint sent to procedure checkpointmanyx was too large causing an error to be returned. This causes XPNET to stop its' backup. An estimate for the size of the checkpoint is calculated before calling checkpointmanyx to prevent this (by doing multiple checkpoints). That estimate is too low now that XPNET is a native process. Change: Changed the calculation for the estimated size of checkpoint messages based on different requirements for native processes. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: None. SCR #3332 SSLCLI - rel3_ver0_sslc02_060620 20-JUN-06 rel3_ver0_tcpl23_060620 SSLSRV - rel3_ver0_ssls02_060620 rel3_ver0_tcpl23_060620 Reference: Internal Symptom: None. Problem: Wrong literal is used for call to STRING_UPSHIFT_. Literal used had a value of 47. Field length in fact was 24. Change: Removed the literal and set the param to 24. Implementation: Move in the new SSLSRV, TCPSRV, GOTCPSRV and CTSE modules. Stop any of the associated stations. Stop and re-start SSLSRV and TCPSRV. Re-start the previously stopped stations. See implementation guide. Dependencies: None. SCR #3335 BASE - rel3^ver1^gate07^20060609 09-JUN-06 - rel3^ver1^base^rel13^20060609 Reference: Case 414398 Symptom: Service providers are not available to another node across a started LINK. For example, if process X on NODE P1B^NODE provides service S1 and P1B^NODE has a started LINK to P1A^NODE, P1A^NODE knows that there are providers configured to provide service S1 on P1B^NODE, but P1A^NODE thinks there are no providers available. Thus, messages routed to the S1 service on P1A^NODE queue to the S1 unavailable service queue. This only happens for service providers (process or station) configured with SMT = -1. Problem: A bug was introduced XPNET 3.1 code release which caused a process/station providing a service to appear to have reached SMT when SMT is configured with a -1 value. This caused the node to treat the provider as an unavailable provider when transmitting available services to other nodes. Change: Fixed the code so that the NODE service transmit functionality works correctly when a service provider has SMT set to -1. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: None. SCR #3345 SVNCSP - SVNCSP-31-04 26-JUL-06 SVNCSP24 - SVNCSP-NET24-31-04 NCSPREPT - NCSP-REPORT-REL31-03 - SVTAB-A-31-04 Reference: 416699 Symptom: ONCF Security Profile shows SAVEABEND as a valid attribute for the ALTER NODE command. SAVEABEND is no longer optional but required under XPNET 3.1 and thus is no longer configurable. Problem: NCSP server still allowed the configuration of a ALTER NODE, SAVEABEND command. Change: Removed SAVEABEND as a valid ALTER NODE command. Implementation: Install the new NET24 and BASE24 NCSP server objects on the XPNET subvol. From within PATHCOM initiate the following command: =FREEZE SERVER-NCSP =FREEZE SERVER-N24NCSP =STOP SERVER-NCSP =STOP SERVER-NCSP =STOP SERVER-N24NCSP =STOP SERVER-N24NCSP =ALTER SERVER-NCSP,PROGRAM $.XPNET.SVNCSP =ALTER SERVER-N24CSP,PROGRAM $.XPNET.SVNCSP24 =THAW SERVER-NCSP =THAW SERVER-N24NCSP Dependencies: XPNET 3.1 only. SCR #3326 SVNCP - rel3^ver0^ncp17^060601 01-JUN-06 SVNCPI - rel3^ver0^rel35^060601 - rel3^ver0^ncp32^060601 SVNCP - rel3^ver1^sncp03^20060601 SVNCPI - rel3^ver1^rel12^20060601 - rel3^ver1^ncp10^20060601 Reference: Case #410692 Symptom: SVNCP abends with trap #2015 in CMD_VALID_RESP, showing the following stack trace: Num Lang Location ABEND 0 TAL #NCP_DUMP.#9816(NCP16TS) + %10I 1 TAL #CMD_VALID^RESP.#3149(NCP16TS) 2 TAL #CMD_COMPLETION.#2036(NCP16TS) + %4I 3 TAL #REL3^VER0^NCP16^050706.#1673(NCP16TS) + %6I Problem: This problem was experienced by a customer using an ONCF client process they had written. The client performed a SERVERCLASS_SEND_ of a STATUS STATION command to SERVER-NCP, specifying a read count larger than is currently used by NCPCOM and requesting the maximum number of responses. This exposed a bug in the SVNCP code where SERVER-NCP was not correctly checking whether it had adequate room in the response message it was building before sending a request to one of the SERVER-NCPIs in the network. Additionally, the SERVER-NCPI which received the request did not properly format the error response which it had to return to SERVER-NCP in a smaller than expected buffer. The invalid response from SERVER-NCPI caused SERVER-NCP to abend. Change: Modified the SVNCP code to properly check the amount of room it has left in the response buffer before sending the request to additional SERVER-NCPIs. Also modified the SVNCPI code to properly format responses when the response buffer is smaller than expected. Implementation: Install new SVNCP and SVNCPI modules on the XPNET subvolume and stop all NCP and NCPI server processes from TACL. Dependencies: None. SCR #3327 NCPCOM - rel3^ver1^ncpc11^20060601 01-JUN-06 rel3^ver1^ncpl10^20060601 SVNCS - rel3^ver1^sncs10^20060601 rel3^ver1^ncpl10^20060601 Reference: Case 413915 Symptom: NCPCOM dumps when using attribute filter when logging. Problem: The proc calls used for the STATUS, STATISTICS, RESETSTATS, START, STOP, and ABORT commands did not include the extensible parameters used for the attribute filters. The np^process^filter proc references these parameters and because they were not included in the call, memory was written over. This could cause the log file address to be incorrect and cause NCPCOM to dump when logging. Change: Corrected the proc calls to include the attribute parameters. Also, corrected a problem with the priority filter and priority attribute filter with the PROCESS and STATION objects. PRIORITY is a attribute for a PROCESS object but not a STATION object so an INFO PRO *,PRIORITY is valid, but INFO STA *,PRIORITY is not valid. The station command with priority requires an integer value (refers to the AUTOPRI attribute). Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1. SCR #3329 SVNCP - rel3^ver0^ncp17^060601 05-JUN-06 SVNCP - rel3^ver1^sncp03^20060601 Reference: Internal, case 414107 Symptom: SVNCP abends with trap #2168 in UT_PUTOOL. Problem: This problem is caused by an invalid buffer initialization statement which initializes more memory than it should. In some exceptional situations, this causes memory tags to be overwritten which is caught as the memory links are validated in UT_PUTPOOL. Change: Fixed the buffer initialization statement that was the causing the problem. Implementation: Install new SVNCP modules on the XPNET subvolume and stop all NCP server processes from TACL. Dependencies: None. SCR #3330 SVNCPI - rel3^ver0^rel35^060601 01-JUN-06 - rel3^ver0^ncp32^060601 SVNCPI - rel3^ver1^rel12^20060601 - rel3^ver1^ncp10^20060601 Reference: Case #414197 Symptom: SVNCPI abends in RCV^CONS in the call to the Guardian INITIALIZER proc. The following Guardian error shows up in the stack: "INITIALIZER: Backup takeover and flags.<12> reset" Problem: With the SVNCPI running with a backup process, the primary PID was stopped or experienced a takeover followed by a stop or failure of the new primary PID prior to the stack getting checkpointed to the new backup SVNCPI process. There was a delay in the code so that the stack was not checkpointed until the next ONCF command was received. Change: Modified the code so that the checkpoint of the stack and globals takes place immediately after the takeover happens. This virtually eliminates the window during which this saveabend can happen. Implementation: Install new SVNCPI module and stop all NCPI server processes from TACL. Dependencies: None. SCR #3331 SVNCPI - rel3^ver1^rel12^20060601 01-JUN-06 - rel3^ver1^rn06^20060601 - rel3^ver1^evt02^20060601 NCPETCL - s31ncpi.ncpi02ea NCPEDDL - s31ncpi.ncpi02es NCPETAL - s31ncpi.ncpi02et NCPTPLS - s31ncpi.ncpi02ps NCPTPLO - s31ncpi.ncpi02po Reference: Case #414198 Symptom: SVNCPI abends with trap #1000 in STOP^PROCESS after getting an error opening the home terminal. Problem: The saveabend occurs because the home terminal cannot be opened (no longer exists?). The code should log an event rather than writing a message to the home terminal. Change: Modified the code to log an event in two places where it currently writes a message to the home terminal. Implementation: Install new SVNCPI module and stop all NCPI server processes from TACL. Re-install all EMS templates using the SCRIBE.GOINST macro. Dependencies: None. SCR #3333 SVNCPI - rel3^ver1^rel12^20060601 07-JUN-06 - rel3^ver1^sec03^20060523 Reference: Case #412165 Symptom: SVNCPI stops generating events to the proper EMS collector at some point after initialization. Problem: New logic to support XPNET 3.1 enhancement I410 to allow command access flags of "U" and "V" added an uninitialized pointer to a structure. At some point during processing, this bad pointer caused the EMS collector name in globals to be corrupted. Change: Changed the logic to declare the structure on the stack instead of using a pointer. Implementation: Install new SVNCPI module and stop all NCPI server processes from TACL. Dependencies: None. SCR #3334 RELPROC - ver JUN2006, file u31relp.relp03as 08-JUN-06 (with this fix, RELPROC is being release for XPNET 3.0 in addition to XPNET 3.1) Reference: Internal, case 413793 Symptom: When processing a TNS/E object with symbols stripped, RELPROC will fail with the following error: Stopping process 3,1200 ... #CHARGETV src_ind src1 1 FOR -1 ^ Expecting a number or an arithmetic expression (Its value must be between 0 and 9223372036854775807 inclusive) Routine Trace: SINK [ enoft_get_proc_detail ^ Error occurred, terminating ... Problem: RELPROC was not correctly handling eNOFT data returned for TNS/E objects with symbols stripped. Change: Fixed RELPROC to provide minimal rel-proc information for TNS/E objects when symbols have been stripped. Implementation: Install the new RELPROC macro file on the XPNET subvolume. Dependencies: None. SCR #3336 NCPCOM - rel3^ver1^ncpc11^20060601 14-JUN-06 - rel3^ver0^ncpc39^060614 Reference: Case 414789 Symptom: NCPCOM dumps when a comma is entered after the FC in the FC command, ex. FC, or FC,DETAIL. Problem: Parsing routine didn't allow for a comma as a deliminter because the FC command does not support filters or modifiers and called abend if parsing failed. Change: Added DLIMCOMMA to prevent the abend when parsing to strip the command word. Added another parse specifically for a comma and return a syntax error. Implementation: Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1 and 3.0. SCR #3344 NCPCOM - rel3^ver1^ncpc12^20060726 26-JUL-06 Reference: 416830 Symptom: INFO PRO *,SMT within an OBEY file does not display correct attribute data. Problem: The global req^attfilt flag is being reset before all objects have been processed causing the format display routine to process the command response as a non-detail response. Change: Removed initialization of the global req^attfilt flag when processing an OBEY command. It should not be initialized at that point in the command processing. Implementation: Install new files on the XPNET subvolume. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1 only. SCR #3346 NCPCOM - REL3^VER1^NCPC12^20060726 27-JUL-06 REL3_VER1_XNCU04^20060727 SVNCS - REL3^VER1^SNCS11^20060726 REL3_VER1_XNCU04^20060727 XNCGEN - REL3_VER1_XNCG06_20060727 Reference: Cases 407397 & 410559. Symptom: INFO,XNCDETAIL command fails with one of the following errors: GET_XNCONF_PRETTY error: PROCESS NOT FOUND Name not found in XNC. Problem: String compare bugs in XNCGEN and in the XNCONF pretty display routines cause various problems with creating the XNCONF and displaying output. Change: Corrected the string compare statements. Implementation: Install the new object files on the XPNET subvolume. Dependencies: XPNET 3.1 Only. SCR #3347 NCPCOM - rel3^ver1^ncpc12^20060726 27-JUL-06 rel3^ver1^ncpl11^20060727 REL3_VER1_XNCU04^20060727 SVNCS - rel3^ver1^sncs11^20060726 rel3^ver1^ncpl11^20060727 REL3_VER1_XNCU04^20060727 Reference: Case 413557 Symptom: INFO PRO,XNCDETAIL shows wrong [aci.xpnet. symbolicdest] value. Problem: Need to pass alias name and process name and use the alias name when present for the binary search. Change: Added alias name to parameter list for XCONF_BINARY_SEARCH and GET_XCONF_PRETTY. Implementation: Install new files on the XPNET subvolume. Freeze/Stop/Thaw SERVER-NCS (SVNCS) from Pathway. Exit any running NCPCOMs and use the new NCPCOM object provided. Dependencies: XPNET 3.1 Only. SCR #3348 XNCGEN - REL3_VER1_XNCG06_20060727 27-JUL-06 RPCGEN - REL3_VER1_RPCG05_20060727 Reference: Case 405415 Symptom: XNCGEN or RPCGEN ABENDs and produces a ZZSA file when executed with an incorrect filename for the INFILE. Problem: We allow the STDFILES pragma to get defaulted allowing the C library to open the STDIN, STDOUT and STDERR. This then causes the saveabend because we are not controlling the STDFILES. Change: Change the code to not allow the C library to control the STDFILES and control the file opens and writes with our own code for errors and output messages. Implementation: Install new XNCGEN and RPCGEN object files. Dependencies: XPNET 3.1 only. SCR #3349 XNCGEN - REL3_VER1_XNCG06_20060727 27-JUL-06 RPCGEN - REL3_VER1_RPCG05_20060727 Reference: Case 407305 Symptom: XPNET dumping in PROCESS^CONTROL^TASK subproc LOAD^XNCPRO^DATA during a start process. Problem: XNCGEN left a bad file after a failed execution. Change: Fixed XNCGEN to purge files upong abend/failure and set an additional validation flag in the header of the file at the very end of XNCGEN processing. A similar fix was made to RPCGEN. The flag will be checked by XPNET to ensure the file is correct. Implementation: Install new XNCGEN and RPCGEN object files. Dependencies: XPNET 3.1 only. SCR #3351 CPCGEN - REL3_VER1_CPCG00_20060814 14-AUG-06 CPCGENGO - n31cpcg.cpcg00as NCPCOM - REL3^VER1^NCPC12^20060726 - REL3^VER1^NCPL11^20060727 NCPDC - s31ncpi.ncpi07dc NCPDCB74 - s31ncpi.ncpi07dv NCPDCOB - s31ncpi.ncpi07dx NCPDDDL - s31ncpi.ncpi07ds NCPDFUP - s31ncpi.ncpi07dz NCPDTAL - s31ncpi.ncpi07dt NCPDTCL - s31ncpi.ncpi07da NCPETCL - s31ncpi.ncpi03ea NCPEDDL - s31ncpi.ncpi03es NCPETAL - s31ncpi.ncpi03et NCPTPLS - s31ncpi.ncpi03ps NCPTPLO - s31ncpi.ncpi03po NCSPREPT - NCSP-REPORT-REL31-04 - REL3_VER1_CPCU00_20060814 POBJ - T3270-N24NCSP (D30) 20 SEP 2006 17:49:01 - T3270-NCSP (D30) 20 SEP 2006 17:59:15 - T6520-N24NCSP (D30) 20 SEP 2006 17:49:28 - T6520-NCSP (D30) 20 SEP 2006 17:59:43 SVNCPI - REL3^VER1^REL13^20060818 - REL3^VER1^NCP11^20060818 - REL3^VER1^EVT03^20060818 - REL3^VER1^OBJ08^20060818 - REL3^VER1^RN07^20060818 - REL3^VER1^SEC04^20060818 - REL3^VER1^UT02^20060818 - REL3^VER1^BKUP03^20060818 SVNCS - REL3^VER1^SNCS11^20060726 REL3^VER1^NCPL11^20060727 SVNCSP - SVNCSP-31-05 - REL3_VER1_CPCU00_20060814 SVNCSP24 - SVNCSP-NET24-31-05 - REL3_VER1_CPCU00_20060814 Reference: ACI Work Order 060515-01 ONCF DELIVER Command Enhancement Symptom: N/A Problem: N/A Change: Modified ONCF modules for the DELIVER command security enhancement. This enhancement will allow users to use ONCF security to secure DELIVER commands by command text, object type and object name patterns. This change requires the use of the new Command Profile Configuration (CPConf) file which will contain the user-generated security configuration for the the DELIVER commands. The security configuration for these commands must be written as XML source code using predefined tag elements and then 'compiled' into a CPCONF extended data segment (EDS) file that the NCPI server can understand. SVNCSP and SVNCSP24 have been modified to recognize when a CPCONF is to be used and include the CPCONF data in the NCSP report. SVNCPI has been modified to use the CPCONF when validating security for DELIVER commands. NCPCOM and SVNCS have been modified to display a new response code from SVNCSPI if the CPCONF is expected but not found. NCSPREPT stand-alone report utility has been modified to include command profile from the CPCONF. CPCGEN is a new utility used to generate the CPCONF EDS from XML source code. For detailed information, please consult the ACI document, NET24-XPNET Command Profile Configuration Guide (publication number XN-NT000-50). Implementation: Install the new object files on the XPNET subvolume. The new NCSP requesters must be copied (using SCUP) into the POBJ files on the XPNET subvolume. Stop all NCPI server processes from TACL. Re-install all EMS templates using the SCRIBE.GOINST macro. Please consult the ACI document, NET24-XPNET Command Profile Configuration Guide (publication number XN-NT000-50) for all the steps required to implement the new enhanced security for DELIVER commands. This document will be available on the ACI HELP24 website on the InfoLink page (InfoLink->Publications->NET24). Dependencies: XPNET 3.1 only. SCR #3339 BASE - REL3^VER1^BASE^REL14^20060710 10-JUL-06 GLOBAL - N31GLBL.GLBL08TG CTS - REL3^VER1^CTS04^20060710 Reference: Internal Symptom: None Problem: None Change: Some internal debugging facilities were enhanced. Dependencies: None SCR #3341 BASE - REL3^VER1^EXEC07^20060710 17-JUL-06 REL3^VER1^BASE^REL14^20060710 Reference: 406384 Symptom: Line and station names run together in EMS events #6235 and #6236. Problem: GEN stats for abnormal lines and stations does add a space between object names making it difficult to read if an object name is 16 characters. Change: Added space to end of line and station object for the GEN stats EMS events #6235 and #6236. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: None. SCR #3342 BASE - REL3^VER0^EXEC28^060710 17-JUL-06 REL3^VER0^REL67^060710 BASE - REL3^VER1^EXEC07^20060710 REL3^VER1^BASE^REL14^20060710 Reference: Internal Symptom: AWAITIOX is called multiple times in the same "tic" receiving error 40. This symptom most likely occurs when XPNET is not busy, and is probably not noticeable externally. Problem: XPNET calls AWAITIOX for the shortest pending timer. If that timer expires in "zero tics", AWAITIOX is called with a zero timelimit after which timers are "aged" for execution (if timers are being "aged" in the same tic as last time, no action is taken). If an I/O doesn't complete, this can occur a number of times before the clock advances to the next tic. This is more likely to occur with faster processors (Itanium), and is more likely as the number of timers increases (i.e. lines with error analysis interval timers). Change: Changed XPNET so timers that expire in "zero tics" are serviced immediately so AWAITIOX is not called with a zero timelimit. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: None. SCR #3352 BASE - rel3^ver1^base^rel14^20060710 28-AUG-06 - rel3^ver1^proc07^20060601 - rel3^ver1^nstp04^20060626 Reference: Case 410617 Symptom: Satellite processes configured with ADOPT ON receive the ACI startup message after the NETWORK is restarted even when the setting of XPNETSTARTSEQ is OFF. Problem: The logic added to support adopted processes was not managing the startup messages sent flag properly which caused the XPNET startup message to always be sent. Change: Changed the logic to set the internal process aci^startup^message^sent flag to true when XPNET adopts a satellite process and then check this flag to prevent XPNET from sending its startup message when it should not. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: XPNET 3.1 only. SCR #3353 BASE - rel3^ver1^base^rel14^20060710 28-AUG-06 - rel3^ver1^proc07^20060601 - rel3^ver1^nstp04^20060626 Reference: Internal Symptom: XPNET abnormally terminates with a code 6501 after a non-stop takeover. Problem: Logic added under XPNET 3.1 to manage segments did not get called if the new backup process could not be created after a takeover. If this new logic was not called, it left the segment table in an inconsistent state if the previous primary allocated any segments which where not also check allocated. The segment id in the table was checkpointed as in use, but after the takeover it was not allocated. When a segment in the new primary was allocated with this segment id it failed a sanity check and dumped with a 6501. Change: Added additional logic to clean up the segment table if the new backup creation fails. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: XPNET 3.1 only. SCR #3354 3.0 POBJ - T3270-NCSS (D21) 28 JUN 1999 16:13:46 30-AUG-06 T6520-NCSS (D21) 28 JUN 1999 16:14:47 3.1 POBJ - T3270-NCSS (D30) 29 JUN 1999 09:46:48 T6520-NCSS (D30) 29 JUN 1999 09:47:40 Reference: Case 419050 Symptom: When using the SEC screen ADD LIKE function the screenlocks up and the NCSS server starts to utilize a large portion of the CPU. Problem: No NCSS file had been created. When the NCSS server replied to the requester with an error 11, the requester failed to recognize the error and retried the request indefinitely without notifying the operator of the problem. Change: Modified the requester to recognize the error and return an error message back to the operator. The following error message is displayed: ERROR READING ALIAS FOR ADD LIKE FUNCTION ON NCSS FILE Implementation: Install the new XPNET POBJ. Dependencies: None. SCR #3358 NCPCOM - rel3^ver1^ncpc13^20060929 29-SEPT-06 Reference: Case 418828 Symptom: Wild-carded LISTOBJECT NCPCOM command will display 19 bytes of invalid data if one or more node(s) returns a failed response, e.g. no obj met filter criteria. Problem: A new line was established at the wrong point. Change: Altered NCPCOM to correctly display LISTOBJECT results. Implementation: Install new files on the XPNET subvol. Execute the NCPCBLD Macro to build the NCPCOMX object and update the ONCF userid and password. NCPCBLD Do you wish to build NCPCOMX file? (Y or N)y BIND/IN NCPCOMB, OUT $S.#NCPSEC/ This TACL routine updates the NCPCOMX object file with a user name and password for ONCF security. The Guardian user executing this routine must have write access to the code files on this subvolume. Searching for files to update for ONCF security... NCPCOMX Mod: 5/11/2006 9:59:10 "CCCC" 154,172 Do you wish to update this file? (Y or N)y Please enter the user ID:super/oper Please enter the password: Updating NCPCOMX... Code file $SYSACI.XPNET.NCPCOMX has been updated Dependencies: None. SCR #3361 TCPCLI/SSLCLI - rel3_ver0_sslc04_061030 30-OCT-06 rel3_ver0_tcpc31_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 TCPSRV/SSLSRV - rel3_ver0_ssls04_061030 rel3_ver0_tcps35_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 CTSEPLO - $data01.n30ctse.ctse07po Reference: Case #420754 Symptom: After a network outage XPNET TCPIP station logs a message indicating a Guardian error 210 ( device ownership changed ) and that it is transitioning from the STARTED state to SUSPENDED state. However a status from NCPCOM shows that the station is in the STARTED state. The client is unable to send messages to this station. Problem: There were two problems. 1). The code was not setting the recv_nw_pending flag to false after a recv error. When XPNET was notified about the error 210 it went into suspend logic and sent a CTS_SUSPEND request to TCPSRV. TCPSRV checks the recv_nw_pending flag to deteremine if it needs to post a RECV_NW. The recv_nw_pending flag was still TRUE because it was never set after the RECV_NW completed with the error 210. TCPSRV never reposts the RECV_NW. 2). On receiving the CTS_SUSPEND TCPSRV code incorrectly signaled the FSM event CTS_SUSP_NOT when it should have signaled CTS_SUSP_OK, because of this XPNET was never notified that the SUSPEND completed and NCPCOM reported station in the STARTED state. Change: Added code to set the recv_nw_pend flag to false on a recv completion with an error. Added code to FSM event CTS_SUSPEND_OK on recepit of a CTS_SUSPEND request from XPNET. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3362 TCPCLI/SSLCLI - rel3_ver0_sslc04_061030 30-OCT-06 rel3_ver0_tcpc31_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 TCPSRV/SSLSRV - rel3_ver0_ssls04_061030 rel3_ver0_tcps35_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 CTSEPLO - $data01.n30ctse.ctse07po Reference: Case #401567 Symptom: The following is logged by EMSPERUS: ERROR: EMSTEXT FAILED ON ATTEMPT TO PRODUCE TEXT FOR EVENT UPPER WORD OF ERROR VALUE IS 12 LOWER WORD OF ERROR VALUE IS 14 05-10-04;11:35:02.790 \K9.$SRV ACI.XPCTSE.3000 1008 Backup process ? created. Problem: CTSE logs the above messaage with the xpctse-tkn-phandle token. This token instructs EMS to resolve the PHANDLE to a printable form to log. If the process is no longer running when EMS attempts to resolve the PHANDLE an error occurs and the above error is logged. Change: Changed the code to resolve the phandle to a string and log the message using the xpctse-tkn-char-var token. EMS will now store the PPD name of the process and can log message 1008 when the process no longer exists without the error. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3343 BASE - REL3^VER1^BASE^REL16^20061030 30-OCT-06 - REL3^VER1^AUD03^20061030 - REL3^VER1^DCOM06^20061030 - REL3^VER1^EXEC09^20061030 - REL3^VER1^GATE08^20061030 - REL3^VER1^MMGR04^20061030 - REL3^VER1^ONCF^CJ03^20061030 - REL3^VER1^ONCF^DEST05^20061030 - REL3^VER1^ONCF^LNK04^20061030 - REL3^VER1^ONCF^ONCF05^20061030 - REL3^VER1^ONCF^PRO09^20061030 - REL3^VER1^ONCF^STA06^20061030 - REL3^VER1^ONCF^SYS11^20061030 - REL3^VER1^PROC08^20061030 - REL3^VER1^QUE05^20061030 GLOBAL - n31glbl.glbl09tg DDLC - s31sddl.sddl04dc DDLCOB - s31sddl.sddl04dx DDLFUP - s31sddl.sddl04dz DDLS - s31sddl.sddl04ds DDLTAL - s31sddl.sddl04dt NCPDC - s31ncpi.ncpi08dc NCPDCOB - s31ncpi.ncpi08dx NCPDCB74 - s31ncpi.ncpi08dv NCPDDDL - s31ncpi.ncpi08ds NCPDFUP - s31ncpi.ncpi08dz NCPDTAL - s31ncpi.ncpi08dt NCPDTCL - s31ncpi.ncpi08da NETDDLS - n31glbl.gddl03ds NETDC - n31glbl.gddl03dc NETDTAL - n31glbl.gddl03dt NETDFUP - n31glbl.gddl03dz NETETCL - n31ems.ems07ea NETEC - n31ems.ems07ec NETEDDL - n31ems.ems07es NETETAL - n31ems.ems07et NETECOB - n31ems.ems07ex NETTPLO - n31ems.ems07po NETTPLS - n31ems.ems07ps NETADRD - rel3^ver1^audr04^20061031 NETCJRD - rel3^ver1^cjrp03^061030 rel3^ver1^rlbk01^20061030 NETDMPRD - rel3^ver1^dmqe04^20061030 NCPCOM - rel3^ver1^ncpc14^20061030 - rel3^ver1^ncpl12^20061030 - rel3^ver1^rlbk01^20061030 SVNCPI - rel3^ver1^rel14^20061030 - rel3^ver1^ncp12^20061030 - rel3^ver1^obj09^20061030 - rel3^ver1^rn08^20061030 SVNCS - rel3^ver1^sncs12^20061030 - rel3^ver1^ncpl12^20061030 - rel3^ver1^rlbk01^20061030 SVNCSP - svncsp-31-06 - svtab-a-31-05 NCSPRPT - ncsp-report-rel31-05 SVNCSP24 - svncsp-net24-31-06 - svtab-a-31-05 NLIB - rel3_ver1_nlib12_060721 NLIBDC - n30nlib.nlib05dc NLIBDCOB - n30nlib.nlib05dx NLIBDDDL - n30nlib.nlib05ds NLIBDTAL - n30nlib.nlib05dt NLIBEXTC - n31nlib.nlib12ce NLIBEXTS - n31nlib.nlib12te HTTPLIB - rel3_ver1_http10_061030 - rel3_ver1_http_util06_061030 HTTPDC - u31http.http03dc HTTPDCOB - u31http.http03dx HTTPDTAL - u31http.http03dt HTTPDDDL - u31http.http03ds MHDRLIB - rel3_ver1_mhdr10_061030 MHDRCEXT - n31mhdr.mhdr10ce MHDRTEXT - n31mhdr.mhdr10te PAYLLIB - rel3_ver1_payl_rel06_061030 - rel3_ver1_payl04_061030 PAYLCEXT - n31payl.payl04ce WGI - rel3^ver1^wgi04^20061030 PXSY31 - File modification 15DEC2006 21:14 - sysaci/sysweb/sate.o (ver 10) PXSY31L - listing of above files (15DEC2006 21:14) PXSY323 - File modification 15DEC2006 20:55 - sysaci/sysweb/sate.o (ver 10) PXSY323L - listing of above files (15DEC2006 20:55) XNLIB.XNLIB - REL3_VER1_XNLIB_REL20_060801 - REL3_VER1_NLIB12_060721 - REL3_VER1_MHDR10_061030 - REL3_VER1_HTTP10_061030 - REL3_VER1_HTTP_UTIL06_061030 - REL3_VER1_PAYL_REL06_061030 - REL3_VER1_PAYL04_061030 XNLIB.XNLIBN - (same mods as XNLIB.XNLIB) XNLIB.XNLIBR - (same mods as XNLIB.XNLIB) XNLIB.XNLIBEN - (same mods as XNLIB.XNLIB) XNLIB.XNLIBER - (same mods as XNLIB.XNLIB)01 XNLIB.XNDC - n31nlib.nlib05dc - u31http.http03dc XNLIB.XNDCOB - n31nlib.nlib05dx - u31http.http03dx XNLIB.XNDTAL - n31nlib.nlib05dt - u31http.http03dt XNLIB.XNCEXT - n31nlib.nlib12ce - n31mhdr.mhdr10ce XNLIB.XNCEXT - n31nlib.nlib12te - n31mhdr.mhdr10te Reference: Large Message Support Enhancement Symptom: None. Problem: None. Change: Modified XPNET to support large multi-chunk messages routed between processes and selected communications protocols. With this enhancement the maximum message size supported will be increased significantly (10MB will be allowed). Implementation: NOTE: If application processes need to support large messages as implemented with this enhancement, application code changes will be required (see notes below). Note that the SKELB API will not support large messages, only the XNLIB API. Install the new XPNET files on the XPNET subvolume. Install the new XNLIB files on the XNLIB subvolume. On the XPNET subvolume, rebuild the NETWORK object using the NETBC obey file. If the customer uses the APPLIB library, it should be rebuilt using the APPLIBBC and APPLIBB files to include the modified HTTPLIB, MHDRLIB and PAYLLIB libraries. Follow the directions in APPLIBB for completing this process. The resulting APPLIB object can be renamed to SKELB if desired. If on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. APPLIB may also be accelerated separately by obeying the APPLAXCL file. The non-native XNLIB library object can be accelerated using the XNLIB.XNAXCL obey file. If using an Itanium NonStop machine (NS-Series), accelerate appropriate files using the following OCA macros: - XPNET.OCAAPPL (for XPNET.APPLIB, if rebuilt) - XPNET.OCANCPI (for XPNET.SVNCPI) - XPNET.OCANETAD (for XPNET.NETADRD) - XPNET.OCANLIB (for XPNET.NETLIB) - XNLIB.OCAXNLIB (for XNLIB.XNLIB) Application processes which use SKELB, XNLIB or XNLIBN as a run-time library must be stopped and restarted in order for the new library to take effect. Application processes which bind one of the above libraries must be re-compiled or re-bound with the new library. Re-install all EMS templates using the SCRIBE.GOINST macro. Stop and restart all XPNET nodes. Stop all the NCPI servers from TACL. Freeze/Stop/Thaw all active SVNCS, SVNCSP servers from Pathway. If security is enabled, update the approriate NCSP records to allow access for the new NODE MAXLARGEMSGSIZE attribute. If Large Message Support is going to be used (i.e. if you have a requirement to route messages larger than 32000 bytes through your XPNET system, or messages larger than 18000 bytes without multi-message checkpointing being performed), alter the new NODE MAXLARGEMSGSIZE attribute to indicate the maximum allowable message size (bytes) that is to be supported. By default, no action is required to continue without large message support. If using NET24-XPNET Web Application Services (Satengine) perform the following steps to install and use the new Satengine code. The sample commands are to aid in the discussion, actual commands may vary from site to site and should be executed with caution. 1) Restore the PXSY* files mentioned above to the XPNET Guardian subvolume. If the XPNET subvolume is on a virtual disk, copy the PXSY* files to a temporary subvolume on a non-virtual disk and use those in step 2. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3) If installing on a S-Series NonStop system (non- Itanium) copy the 'sate.o' file from the temporary directory to the installation directory. If installing on an Itanium NS-Series NonStop system, copy the 'satengine' file from the temporary directory to the installation directory. Example (save the old sate.o file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/zzold Example (install the new sate.o file): > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. 4) If installing on an S-Series NonStop system (non- Itanium) make the sate executable object file. Use the appropriate make file for the NSJ version you are using. For example, if using NSJ4: > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). 5) Stop all satengine processes. 6) If installing on an S-Series NonStop system (non- Itanium) copy the new sate object from step 4 to its runnable location. For example: > mv -i satengine old_sategine (rename old out) > mv -i sate satengine (rename new in) If installing on an S-Series NonStop system (non- Itanium) use the 'satengine' file provided (see step 3) 7) Start satengine processes. 8) Purge temporary subvolumes and directories created in steps 1, 2 and 3. If an application process is going to send or recieve messages larger than 32000 bytes (or if messages larger than approximately 18000 bytes are being split into multiple chunks), the application will require code changes to implement the large message support added to the XNLIB API library. If messages less than 64K bytes in length are going to be supported, the changes are mainly to pass in several new parameters to the NETLIB_INIT procedure at application initialization. If messages larger than 64K bytes are required, further changes are required, mainly allowing the application to receive the chunks from the NODE and call the new XNLIB procedure NETLIB_RCV_LARGEMSG_CHUNK to piece the message together. Sending messages larger than 64K bytes will require the application to call the new NETLIB_SEND_LARGEMSG procedure. See further details as documented in the NET24-XPNET Application Programming Reference Manual (changes forthcoming). If large messages coming in through WGI stations from WebGate are larger than 18000 bytes and causing multi- message checkpoints to the XPNET backup process (the STATISTICS NODE, DETAIL command shows the number of multi-message checkpoints that have been peformed by the XPNET process) the DEVICE being used by the WGI stations can be altered to have an XMITLEN of 18000 bytes to elimiate the multi-message checkpoints. Dependencies: All of these changes must be implemented simultaneously or messaging problems may result. SCR #3360 BASE - rel3^ver1^base^rel16^20061030 30-OCT-06 - rel3^ver1^nstp05^20061030 Reference: Case 420483 (internally generated). Symptom: XPNET abnormally terminates in INITIALIZER after a non-stop takeover. Problem: If the primary XPNET process is stopped after the backup is created, but before the stack is checkpointed, INITIALIZER will force an ABEND when the backup takes over. The window where this can occur is VERY SMALL, typically we can only make it happen using debug. Change: Even though this problem is not likely to occur, changes are being made because it is hard to determine the cause. Changed the call to INITIALIZER to pass flags.<12> as true, then if this problem occurs INITIALIZER returns a status of -1 instead of abending. XPNET checks the status and abends if it is -1 because the new primary that is taking over cannot continue. XPNET still goes away, but the reason is easier to determine since the abend originates from XPNET user code. The new primary is in no condition to continue, it cannot use any facilities of the Network, so it can't even log a message. About the only choice is to ABEND. The original primary can't prevent someone from stopping it while it is trying to checkpoint to it's backup, so there isn't much that can be done to prevent this. Implementation: Install the new BASE module on the XPNET subvolume and rebuild the network object. Dependencies: XPNET 3.1 only. SCR #3365 BASE - REL3^VER1^BASE^REL16^20061030 11-NOV-06 REL3^VER1^ONCF^SYS11^20061030 Reference: Case 424129 Case 424986 Symptom: ONCF command INFO LINE *,UNDER RADDR * caused the network to dump. Problem: A pre-existing 3.0 bug will cause an address exception in the 3.1 PTAL NETWORK code. If a line does not have any associated stations then lin.sta^list is zero. Referencing a zero address in PTAL will cause an address exception. In 3.0, this is not causing an address exception. Change: Modified code to check lin.sta^list for zero before using as a reference pointer. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.1 only. SCR #3366 BASE - rel3^ver0^rel69^061212 21-NOV-06 - rel3^ver0^gate30^060714 BASE - REL3^VER1^BASE^REL16^20061030 - REL3^VER1^GATE08^20061030 Reference: Case 422320 Symptom: Memory Alert Threshold exceeded and memory usage continued to increase with no message queues or new configuration added. Problem: XPNET memory leak under a very specific situation. If a discover request message is read from another XPNET node and the requested dest is a service with no local providers the memory for the discover request message is not returned. This became an issue because the requesting XPNET node(s) were not linked to the XPNET node with local service providers and continued to send discover requests which consumed memory on the XPNET nodes it was linked to. Change: Changed the discover logic to return memory on the discover request message in all cases. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If XPNET 3.0 and on RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3367 BASE - rel3^ver0^rel69^061212 21-NOV-06 - rel3^ver0^gate30^060714 BASE - REL3^VER1^BASE^REL16^20061030 - REL3^VER1^GATE08^20061030 Reference: Case 414417 Symptom: Messages queued to an unavailable service queue when the service provider is not busy and available. Problem: SCR 3129 which introduced this issue was intended to prevent a message sent to a service from being routed back to itself if the source process also provides that service. If there is more than one available service provider, this does not cause a problem, the message is routed to another member of the service as intended. However, if there is only one service provider this message will queue in the USQueue. Once this occurs ALL messages routed to this service will queue in the USQueue until a second service provider becomes available or this message is removed from the front of the queue by an operator command. Change: In order to prevent this problem in environments where there is only one service provider, the logic added by SCR 3129 was amended. If there are multiple service providers available, the source process will not be considered as a possible destination under the service for this message. However, if there is only one service provider available, the message will be routed back to the source process process instead of queuing in the USQueue. This allows new messages routed to this service to be processed. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If XPNET 3.0 and on RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3368 NCPCOM - rel3^ver1^ncpl12^20061030 28-NOV-06 rel3^ver1^ncpc14^20061030 SVNCS - rel3^ver1^sncs12^20061030 Reference: Case 423254 Symptom: INFO PROCESS, OBEYFORM doesn't match the INFO PROCESS, DETAIL information for the SMT parameter. Problem: If SMT was set to -1 it was not shown in the INFO PROCESS, OBEYFORM. This implies the SMT is set to the default value however the SMT default is 0. Change: Changed np^format^pro^obeyform so positive non-zero SMT values and -1 are shown in the INFO PROCESS, OBEYFORM. Zero is the SMT default and thus not displayed in the OBEYFORM output. Implementation: Install new files on the XPNET subvolume. Exit any running NCPCOMs and freeze/stop/stop/thaw SVNCS. Dependencies: None. SCR #3369 BASE - REL3^VER1^BASE^REL16^20061030 12-DEC-06 - REL3^VER1^MMGR04^20061030 - REL3^VER1^PROC08^20061030 - REL3^VER1^NSTP05^20061030 - REL3^VER1^EXEC09^20061030 - REL3^VER1^ONCF^SYS11^20061030 BASE - rel3^ver0^rel69^061212 - rel3^ver0^mmgr03^060817 - rel3^ver0^proc37^060816 - rel3^ver0^nstp18^060817 - rel3^ver0^exec30^061212 - rel3^ver0^oncf^sys25^060925 GLOBAL - N31GLBL.GLBL09TG GLOBAL - n30glbl.glbl37tg DDLC - S31SDDL.SDDL04DC DDLCOB - S31SDDL.SDDL04DX DDLFUP - S31SDDL.SDDL04DZ DDLS - S31SDDL.SDDL04DS DDLTAL - S31SDDL.SDDL04DT DDLC - s30sddl.sddl15dc DDLCOB - s30sddl.sddl15dx DDLFUP - s30sddl.sddl15dz DDLS - s30sddl.sddl15ds DDLTAL - s30sddl.sddl15dt NCPDC - S31NCPI.NCPI08DC NCPDCOB - S31NCPI.NCPI08DX NCPDCB74 - S31NCPI.NCPI08DV NCPDDDL - S31NCPI.NCPI08DS NCPDFUP - S31NCPI.NCPI08DZ NCPDTAL - S31NCPI.NCPI08DT NCPDTCL - S31NCPI.NCPI08DA NCPDC - s30ncpi.ncpi19dc NCPDCOB - s30ncpi.ncpi19dx NCPDCB74 - s30ncpi.ncpi19dv NCPDDDL - s30ncpi.ncpi19ds NCPDFUP - s30ncpi.ncpi19dz NCPDTAL - s30ncpi.ncpi19dt NCPDTCL - s30ncpi.ncpi19da NETDDLS - N31GLBL.GDDL03DS NETDC - N31GLBL.GDDL03DC NETDTAL - N31GLBL.GDDL03DT NETDFUP - N31GLBL.GDDL03DZ NETDDLS - n30glbl.gddl15ds NETDC - n30glbl.gddl15dc NETDTAL - n30glbl.gddl15dt NETDFUP - n30glbl.gddl15dz NETETCL - N31EMS.EMS07EA NETEC - N31EMS.EMS07EC NETEDDL - N31EMS.EMS07ES NETETAL - N31EMS.EMS07ET NETECOB - N31EMS.EMS07EX NETTPLO - N31EMS.EMS07PO NETTPLS - N31EMS.EMS07PS NETETCL - n30ems.ems26ea NETEC - n30ems.ems26ec NETEDDL - n30ems.ems26es NETETAL - n30ems.ems26et NETECOB - n30ems.ems26ex NETTPLO - n30ems.ems32po NETTPLS - n30ems.ems32ps NCPCOM - REL3^VER1^NCPC14^20061030 - REL3^VER1^NCPL12^20061030 - REL3^VER1^RLBK01^20061030 NCPCOM - rel3^ver0^ncpc40^060921 - rel3^ver0^ncpl35^060823 - rel3^ver0^rlbk14^061214 SVNCPI - REL3^VER1^REL13^20061030 - REL3^VER1^NCP12^20061030 - REL3^VER1^OBJ09^20061030 SVNCPI - rel3^ver0^rel36^060921 - rel3^ver0^ncp33^060921 - rel3^ver0^obj23^060921 SVNCS - REL3^VER1^SNCS12^20061030 - REL3^VER1^NCPL12^20061030 SVNCS - rel3^ver0^sncs39^061013 - rel3^ver0^ncpl35^060823 SVNCSP - SVNCSP-31-06 - SVTAB-A-31-05 SVNCSP - svncsp-30-16 - svtab-a-30-14 NCSPREPT - NCSP-REPORT-REL31-05 NCSPREPT - ncsp-report-rel30-01 SVNCSP24 - SVNCSP-NET24-31-06 - SVTAB-A-31-05 SVNCSP24 - svncsp-net24-30-16 - svtab-a-30-14 NETCJRD - REL3^VER1^CJRP03^061030 NETCJRD - rel3^ver0^cjrp12^061212 Reference: Case 418341 Symptom: XPNET dumps with a 6410 (out of memory) with memory still available. Problem: Memory fragmentation can cause a 6410. Even though memory was available, the largest free block was not big enough to satisfy the size of the memory allocation request. When a process is started, a dedicated I/O buffer is allocated based on MAXPROMSG size. Some TSS applications require this to be 32000 bytes. If all/most of the processes configured require this buffer size it does not cause fragmentation. The problem occurs if the majority of the processes require a much smaller buffer. Most classic BASE24 applications only need between 1k and 4k bytes. XPNET does not know the actual buffer size requirement until after the process calls NETINIT or NETLIB_INIT with its msg/block size requirements. When this occured, XPNET returned the unneeded part of this buffer which created a fragment of 28k to 31k. Over time, even though node statistics show that a sufficient amount of memory is available it is made up of fragments which can cause a 6410. Change: Modified the logic that causes the fragmentation to occur. Instead of returning the unneeded part of the buffer which created a fragment, the entire initial 32k buffer is returned and a new buffer is allocated for the actual size required. When memory blocks are returned, XPNET will combine adjacent free blocks into one larger free block so this new logic will help prevent memory fragmentation. One of the problems with fragmentation is that it can cause the XPNET node to dump with no warning. There could be MAT events, but these will show memory is available if the memory is fragmented. In order to provide an early indication that memory fragmentation could cause the node to dump a new NODE attribute (MEMFRAGPAGES) was added. If the size of the largest free block drops below (MEMFRAGPAGES * 2048) XPNET will generate event 3008. This event may be generated if fragmentation is happening or the XPNET node is running out of memory. You should be able to determine this from the information in the event. If fragmentation is happening, you should increase the size of XPNET's extended segment. This can be done with two ONCF commands: ALTER NODE , EXTPAGES CONTROL NODE , RESIZESEGMENT 06-12-01;11:07:33.568 \SYS1.$P1AN ACI.XPNET.3000 3008 Memory Fragment Alert Threshold exceeded. Largest Free block: Curr: , Prev: , Min: , Max: Smallest Free block: Curr: , Prev: , Min: , Max: Number of Free blocks: Curr: , Prev: , Min: , Max: Current Utilization: 65% Total Bytes: , Total Free Bytes: Event 3008 will occur every memory evaluation delay (MED) until the largest free block size goes back above the memory fragment alert threshold at which time event 3009 will be generated. 06-12-01;11:15:47.839 \SYS1.$P1AN ACI.XPNET.3000 3009 Memory Fragment Alert Threshold no longer exceeded Largest Free block: Curr: , Prev: , Min: , Max: Smallest Free block: Curr: , Prev: , Min: , Max: Number of Free blocks: Curr: , Prev: , Min: , Max: Current Utilization: 60% Total Bytes: , Total Free Bytes: The STATUS and STATISTICS NODE response were modified to display information about the number of free blocks and the size of the largest and smallest free block. STATUS COMMAND: NUMBER FREE BLOCKS: CURR: 5 PREV: 7 LARGEST FREE BLOCK: CURR: 6232000 PREV: 6112000 SMALLEST FREE BLOCK: CURR: 48 PREV: 192 STATISTICS COMMAND: NUMBER FREE BLOCKS: MIN: 1 MAX: 7 LARGEST FREE BLOCK: MIN: 6112000 MAX: 15779498 SMALLEST FREE BLOCK: MIN: 48 MAX: 15779498 Implementation: Install the new object/template files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If XPNET 3.0 and on RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Stop all the NCPI servers from TACL. Freeze/Stop/Thaw SVNCS and SVNCSP. If security is enabled, update the approriate NCSP records. On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. ALTER NODE , MEMFRAGPAGES . The number of pages should be based on a reasonable percentage of EXTPAGES so that a warning event is only generated when there is a problem. The new information from the NODE STATISTICS can help in determining this value. Dependencies: None. SCR #3372 BASE - REL3^VER1^BASE^REL16^20061030 06-DEC-06 REL3^VER1^ONCF^LIN03^20061206 Reference: Case 420421 Symptom: Networked dumped when adding lines. Problem: The network was creating an EMS event to indicate the network was not licensed for the protocol of the line being added. An invalid address was passed in the event buffer. Change: Changed the code to use tkn^addr instead of tkn^subject^lin. Using tkn^addr will cause the event log routine to use the node defaults when checking the ems event flags. Using tkn^subject^lin cause the routine to check the line ems event flags and we do not have addressability to the line table. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.1 only. SCR #3373 BASE - REL3^VER1^BASE^REL16^20061030 12-DEC-06 - REL3^VER1^EXEC09^20061030 Reference: Internal Symptom: Object enters and exits NOM state, messages are properly NOM'd but no EMS events are generated to indicate that messages have been NOM'd. Problem: During changes to support new features under XPNET 3.1 the call to generate the NOM events was accidentally removed. Change: Added back call to LOG^NOM^MESSAGE so that NOM events are generated when an object invokes NOM and when NOM is no longer in progress. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3374 BASE - REL3^VER1^BASE^REL16^20061030 12-DEC-06 - REL3^VER1^EXEC09^20061030 BASE - rel3^ver0^rel69^061212 - rel3^ver0^exec30^061212 Reference: Case #410019 Symptom: XPNET abnormally terminates with a trap 2 in proc LOG^STATISTICS when STATISTICS are generated. STATISTICS are generated when a CONTROL NODE, GENERATE command or a STOP or ABORT NODE command is issued and also when the SINTERVAL timer expires. Problem: If NODE attribute PAYLOADPAGES is set high and EXTPAGES is also high an arithmetic overflow can occur when XPNET is attempting calculate the percent free value for the payload memory statistics. The value of PAYLOADPAGES that causes the trap to occur can vary depending on the number of payload pages in use and the size of the extended segment. Change: Corrected the percent free payload statistics calculation so that a trap will not occur when PAYLOADPAGES are set high. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. WORKAROUND: It would be a very rare case where more than 10,000 pages of memory are required for payload data, so until the fix can be installed, set the NODE PAYLOADPAGES attribute to a value well below 10000. Dependencies: None. SCR #3375 BASE - REL3^VER1^BASE^REL16^20061030 21-DEC-06 - REL3^VER1^EXEC09^20061030 - REL3^VER1^QUE05^20061030 BASE - rel3^ver0^rel69^061212 - rel3^ver0^exec30^061212 - rel3^ver0^que17^061211 Reference: Case #425976 Symptom: XPNET abnormally terminates with a SIGNUM 11 trap in procedure UPDATE^QUEUE^COUNTERS after ONCF command TRACE LINE , DUMP is executed. Problem: The queue type in an internal queue control block (QCB) used by the CTS protocol module was not properly initialized. If the value of this field from a previous memory allocation was 1, 2 or 5 and the XPNET node has MEASURE ON, the logic in UPDATE^QUEUE^COUNTERS assumes the address of the passed QCB is from a process, station or dest and attempts to get addressability to the object to retrieve the configured measure counter name. If the QCB passed is not from a process, station or dest the calculated address may not be valid. When the logic attempts to access the counter name, it can cause the XPNET node to trap. Change: Changed procedure INITIALIZE^QCB to set the default value of queue type to zero ( internal^qcb ) for all QCB's. This prevents UPDATE^QUEUE^COUNTERS from invoking the logic that causes the trap. Internal QCB's should not bump measure counters. Also added code to initialize the entire QCB struct to prevent this in the future. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If XPNET 3.0 and on RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3376 BASE - REL3^VER1^BASE^REL16^20061030 12-DEC-06 - REL3^VER1^EXEC09^20061030 BASE - rel3^ver0^rel69^061212 - rel3^ver0^exec30^061212 Reference: Internal Symptom: Message dropped and EMS event 6340 is generated if a message with msg.disposition not equal to 0 is routed to an unavailable service on another XPNET node. Problem: If a message routed to a service provider on another XPNET node can not be processed, as part of the service based routing logic it is failed back to the originating node to be rerouted or queued. However, if msg.disposition = 1 (log and drop) or 2 (drop), the failure/reroute logic is not invoked because the message is dropped on the external XPNET node. Change: Changed proc RETURN^MSG to fail the message instead of dropping it if the failure code is 110, the message was routed to a service and originated on another XPNET node. The allows the message to fail back to its source XPNET node as intended under the service based routing logic. If the message is failed on the XPNET node it was acquired on, was not routed to a service or for any other failure code, the message will be dropped as the source process requested by setting msg.dispostion <> 0. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If XPNET 3.0 and on RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3379 CTSETPLS - $DATA01.N31CTSE.CTSE02PS 17-JAN-07 CTSETPLO - $DATA01.N31CTSE.CTSE02PO NCPTPLS - $DATA01.S31NCPI.NCPI04PS NCPTPLO - $DATA01.S31NCPI.NCPI04PO NETTPLS - $DATA01.N31EMS.EMS08PS NETTPLO - $DATA01.N31EMS.EMS08PO PMONTPLS - $DATA01.P31PMON.PMON01PS PMONTPLO - $DATA01.P31PMON.PMON01PO SNCPTPLS - $DATA01.S31NCPS.NCPS01PS SNCPTPLO - $DATA01.S31NCPS.NCPS01PO UDPTPLS - $DATA01.N30UDPL.UDP02PS UDPTPLO - $DATA01.N30UDPL.UDP02PO Reference: internal Symptom: XPNET 3.1 EMS template files had data in columns that would be truncated by CXUTIL when loading EVENTCX files. Problem: The program requires that TPLS CAUSE and REMEDY data be between columns 8 and 68. Change: Modified template source files to conform the CXUTIL's requirements. Implementation: replace existing template source and objects on the XPNET subvolume. Incorporate these into the EMSNRES file by running the SCRIBE.TMPLMAKE file and then running the SCRIBE.GOINST macro. Dependencies: None SCR #3380 SKEL - rel3^ver1^sutl08^20070108 08-JAN-07 - rel3^ver0^sutl27^070108 Reference: RPE 061102-01 Symptom: N/A. Problem: Updates to the valid BIN ranges allowed for Discover cards. Sixteen digit PANS within the following primary account number ranges will be deemed Discover card prefixes: "60110000" - "60119999" or "62212600" - "62292599" or "64400000" - "64499999" or "650000" - "659999" Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3384 NCPCOM - rel3^ver1^ncpc15^20070209 09-FEB-07 rel3^ver1^ncpl13^20070209 SVNCS - rel3^ver1^ncs13^20070209 rel3^ver1^ncpl13^20070209 Reference: Case 428125 & 428175 Symptom: ABORT command fails when doing rollback. Problem: The CONFIGURED modifier was removed in the XPNET 3.1 release. The obey file created by rollback used the CONFIGURED modifier with ABORT command. When the file is OBEY it the ABORT command fails with a syntax error causing the rollback to abort. The CONFIGURED modifier was added to the ABORT commands in 3.0 (SCR2555) to correct an "object not found" with DISABLED object during rollback. Removing it 3.1 re-introduced this problem. Change: Added the CONFIGURED modifier back to the ABORT commands. Implementation: Install new files on the XPNET subvolume. Exit any running NCPCOMs and freeze/stop/stop/thaw SVNCS. Dependencies: None. SCR #3387 XNLIB.XNLIB - rel3_ver1_mhdr11_070309 09-Mar-07 rel3_ver1_nlib13_070309 rel3_ver1_xnlib_rel21_070309 XNLIB.XNLIBEN - rel3_ver1_mhdr11_070309 rel3_ver1_nlib13_070309 rel3_ver1_xnlib_rel21_070309 XNLIB.XNLIBER - rel3_ver1_mhdr11_070309 (relinkable) rel3_ver1_nlib13_070309 rel3_ver1_xnlib_rel21_070309 XNLIB.XNLIBN - rel3_ver1_mhdr11_070309 rel3_ver1_nlib13_070309 rel3_ver1_xnlib_rel21_070309 XNLIB.XNLIBR - rel3_ver1_mhdr11_070309 (relinkable) rel3_ver1_nlib13_070309 rel3_ver1_xnlib_rel21_070309 XPNET.MHDRLIB - rel3_ver1_mhdr11_070309 XPNET.NLIB - rel3_ver1_nlib13_070309 Reference: Case #431271 Symptom: XPNET logged event #06067 saying "Network received invalid message/block from Process error 2" and the message was discarded. Problem: The size of the message written to XPNET was smaller than the minimum required for a valid XPNET message. This problem was introduced by SCR3343 (Large Message Support) and could occur when MHDR routine "MHDR_SET_MSG_TEXT" was called with parameters msg_txt_lgth or userdata_lgth having values of -1. A value of -1 (unsigned 65535) is documented as having special meaning to that procedure, SCR3343 inadvertently circumvented the code that handled that special value. The result was that the message length field was set to 65535 (-1). NETLIB procedure "netlib_send" calculates the write count by adding the message length field to the length of an XPNET message header (108) and to the length of any user data in the message yielding a 16 bit int. If that calculation yields a value larger than 65535, it is truncated. For example, if a message had no user data, adding 65535 plus 108 yields 107 which XPNET will not accept (not even long enough for an XPNET header). Change: Modified "MHDR_SET_MSG_TEXT" to reinstate special handling of -1 values for params msg_txt_lgth and userdata_lgth. Modified "netlib_send" to use a 32 bit integer for intermediate calculations. There are considerations for sending large messages, see SCR3343 for details, but one note should be made here. If sending large messages using the "pre large message API", the maximum message text length is 65535 minus 108 minus user data length minus payload length. Implementation: Since XNLIB and APPLIB can be ran as user libraries, do the following only after taking appropriate action to avoid library conflicts. Install the new XPNET files on the XPNET subvolume. Install the new XNLIB files on the XNLIB subvolume. If the customer uses the APPLIB library, it should be rebuilt using the APPLIBBC and APPLIBB files to include the modified MHDRLIB and NETLIB libraries. Follow the directions in APPLIBB for completing this process. The resulting APPLIB object can be renamed to SKELB if desired. If on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. APPLIB may also be accelerated separately by obeying the APPLAXCL file. The non-native XNLIB library object can be accelerated using the XNLIB.XNAXCL obey file. If using an Itanium NonStop machine (NS-Series), accelerate appropriate files using the following OCA macros: - XPNET.OCAAPPL (for XPNET.APPLIB, if rebuilt) - XPNET.OCANLIB (for XPNET.NETLIB) - XNLIB.OCAXNLIB (for XNLIB.XNLIB) Application processes which use APPLIB or XNLIB as a run-time library must be stopped and restarted in order for the new library to take effect. Application processes which bind one of the above libraries must be re-compiled or re-bound with the new library. Dependencies: None. SCR #3382 TCPCLI/SSLCLI - rel3_ver0_sslc05_070202 02-FEB-07 rel3_ver0_tcpc32_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 TCPSRV/SSLSRV - rel3_ver0_ssls05_070202 rel3_ver0_tcps36_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 CTSE - rel3_ver0_ctse20_070202 TCPTPLS - $data01.n30tcpl.tcp10ps TCPTPLO - $data01.n30tcpl.tcp10po CTS - rel3^ver0^cts28^070202 CTSDC - $data01.n30cts.cts06dc CTSDDDL - $data01.n30cts.cts06ds CTSDTAL - $data01.n30cts.cts06dt CTSDTCL - $data01.n30cts.cts06da ******XPNET 3.1****************** CTS - REL3^VER1^CTS05^20070202 CTSDC - $data01.n31cts.cts04dc CTSDDDL - $data01.n31cts.cts04ds CTSDTAL - $data01.n31cts.cts04dt CTSDTCL - $data01.n31cts.cts04da Reference: Case 425545 Symptom: None. Problem: Customer needs to have the RADDR passed to the application in the XPNET message header userdata. Change: Modified to place the RADDR in the XPNET message header userdata. To specify this format, the userdata for the station must contain -R+. The default is -R-. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. In order to have the RADDR passed to the application in the XPNET message header userdata the station USERDATA must be modified to [ -R+ ]. Dependencies: CTS bound into network - rel3^ver0^cts28^070202 CTS bound into network - REL3^VER1^CTS05^20070202 TCPSRV - REL3_VER0_TCPS36_070202 TCPCLI - REL3_VER0_TCPC32_070202 SCR #3394 SVNCP - REL3^VER1^SNCP04^20070426 25-APR-07 Reference: Case 433314 & 433927 Symptom: UNABLE TO SEND COMMAND TO NETWORK returned from DCT commands initiated to an XPNET 3.1 environment. Problem: The FAIL integer added under SCR 2993 for the CONTROL DESTSTATUS command was not initialized to a binary zero but rather contained spaces. Change: Changed NCP Server to initialize the FAIL integer to a binary zero. Implementation: Install new SVNCP modules on the XPNET subvolume and stop all NCP server processes from TACL. Dependencies: None. SCR #3391 TCPCLI/SSLCLI - rel3_ver0_sslc06_070522 22-MAY-07 rel3_ver0_tcpc33_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 TCPSRV/SSLSRV - rel3_ver0_ssls06_070522 rel3_ver0_tcps37_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 CTSETPLS - $data01.n31ctse.ctse03ps CTSETPLO - $data01.n31ctse.ctse03po Reference: Case 426307 Symptom: The Services file is constantly being accessed by the TCPSRV/CLI process. Problem: Code only checks for blanks when deciding to make the call to GETSERVBYNAME. It should verify that the Port number contains alphbetic characters before making the call. Code also overwrites the value returned by GETSERVBYNAME actually making the call useless. Change: Removed the call to GETSERVBYNAME. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3392 TCPCLI/SSLCLI - rel3_ver0_sslc06_070522 22-MAY-07 rel3_ver0_tcpc33_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 TCPSRV/SSLSRV - rel3_ver0_ssls06_070522 rel3_ver0_tcps37_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 CTSETPLS - $data01.n31ctse.ctse03ps CTSETPLO - $data01.n31ctse.ctse03po GOTCPSRV - $data01.n30tcps.gotcps09 GOTCPCLI - $data01.n30tcpc.gotcpc08 Reference: Case 432456 Symptom: Enhancement for Large Remote and Local Address fields for CTS stations. Increased the number of connections the TCPSRV/CLI and SSLSRV/CLI can support. Pior maximum was 510 this was increased to 1000. Problem: None. Change: Enhancement to utilize the larger local and remote address fields for XPNET 3.1 CTS stations. The fields increase from 24 bytes to 56 bytes. Added the MAXRECVSEND param to the GOTCPSRV and GOTCPCLI obey files the default is 4095. This is number of XLCB's the process is allowed. This is increased to allow for the increased number of allowed stations per process. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3398 SVNCSP - SVNCSP-31-07 10-MAY-07 SVNCSP24 - SVNCSP-NET24-31-07 Reference: Case #433536 Symptom: Allocate Segment Error 0001 on CPCONF when running NCSP remotely. Problem: Remote file names can not be used when allocating a segment. This prevents SERVER-NCSP from updating or accessing a NCSP file on a remote node because it tries to allocate the CPCONF segment file. Change: Modified the CPC in use indicator to detect when the allocate segment on the CPCONF fails due to using a remote file name. We will display the text "CPCONF - REMOTE" on the NCSP screen to indicate the NCSP requestor is configured with a remote CPCONF and continue normal operation. if PRINT ONCF COMMAND REPORT (SF13) is executed when accessing a remote CPCONF, the CPCONF data cannot be accessed and the report will display the following message for the CPCONF section: ** DATA CANNOT BE REPORTED WHEN CPCONF IS REMOTE **. Implementation: Freeze/Stop/Thaw SVNCSP. Dependencies: XPNET 3.1. SCR #3395 NCPCOM - rel3^ver1^ncpc16^20070501 01-MAY-07 rel3^ver1^ncpl14^20070501 $data01.s31ncpl.ncpl08ds $data01.s31ncpl.prel08tg SCNCS - rel3^ver1^sncs14^20070501 rel3^ver1^ncpl14^20070501 $data01.s31ncpl.ncpl07tg $data01.s31ncpl.ncpl08ds $data01.s31ncpl.prel08tg Reference: Case #433278 Symptom: INFO STATION DETAIL for SLU stations improperly formatted ENDBRACKEON, PASSFMOFF and SAVEDMSGS displays. Problem: Misalignment between the DDLs and preformatted data fields. Change: Corrected DDLS and preformatted fields then recompiled NCPCOM and server-ncs Implementation: Stop server-ncs. Replace existing NCPCOM and server-ncs objects. No system outage is necessary for this change. Dependencies: None. SCR #3399 NCPCOM - rel3^ver1^ncpc16^20070501 17-MAY-07 Reference: Case 434114 Symptom: NCPCOM loops when processing a SET PROCESS STARTOPTIONS command within a OBEY file. Problem: When a STARTOPTIONS command is more than 80 characters, NCPCOM reads the next line of the OBEY file and appends that line to the end of buffer. If the address pointing to the end is an odd byte address, then the data is appended on a word boundary and the last character is overwritten with the appended data. This will cause the test for determing whether another read is required to be false and cause the loop. Change: Changed the buffer address in the call to read^file to be a byte address using a integer pointer. Implementation: Replace existing NCPCOM object and restart NCPCOM. No system outage is necessary for this change. Dependencies: None. SCR #3408 NCPCOM - rel3^ver0^ncpc41^070607 19-JUL-07 - rel3^ver0^ncpl36^070607 - rel3^ver0^rlbk15^070518 NCPCOM - rel3^ver1^ncpc17^20070720 - rel3^ver1^ncpl15^20070720 - rel3^ver1^rlbk02^20070720 Reference: Case #435246 Symptom: CONTROL NODE , ROLLBACK aborts with STATION USERDATA failed, cmd inv in state starting. If the station did not need to be aborted, the previous userdata value was not put in the rollback command file, it simply changed the station userdata to blanks. Problem: The rollback logic did not generate an ABORT LINE command for the station which was changed. The table that determines if the object needs to be aborted for the command was incorrect for station userdata. Under XPNET 3.0, station userdata was increased from 80 to 200 bytes. This required the rollback logic to break up the alter station userdata into multiple command lines using an offset. This logic did not work. Change: Changed the logic to add an ABORT LINE in the rollback file when an ALTER STATION USERDATA command needs to be rolled back. Fixed the logic to properly format the rollback commands for ALTER STATION USERDATA when multiple lines are required. Implementation: Install new NCPCOM object. Dependencies: None. SCR #3381 BASE - REL3^VER1^PROC09^20070122 22-JAN-07 - REL3^VER1^BASE^REL17^20070122 BASE - rel3^ver0^proc38^070122 - rel3^ver0^rel70^070122 GLOBAL - N31GLBL.GLBL10TG GLOBAL - n30glbl.glbl38tg Reference: Case 418892 Symptom: All available payload memory has been used, and the following events are logged. 07-01-22;11:43:29.144 \X.$P1AN ACI.XPNET.3000 6361 Unable to save payload in memory, all payload memory has been used. NODE PAYLOADPAGES must be increased. 07-01-22;11:43:29.146 \X.$P1AN ACI.XPNET.3000 6357 Error with payload in MSG sent to Process P1A^AUTH. The payload could not be saved in memory for this MSG. Problem: If an application that allows XPNET to manage payload replies to a message with no data, the payload being held by XPNET for that message is not released. Increasing the NODE PAYLOADPAGES and/or decreasing the NODE PAYLOADTIMEOUT MAY provide a temporary work around. The particular problem reported by this case happened because de-SAF processing flooded the Auth process with messages. Classic Auth does not manage payload, so XPNET manages it on Auth's behalf. Change: Changed XPNET to release any payload being held for a message when an application replies to that message with no data. SKEL and NETLIB will reply with no data on the users behalf when the next read is done if the application has not sent a reply. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Dependencies: None. SCR #3403 SATEPLO - W11SATE.SATE05PO 30-May-07 SATEPLS - W11SATE.SATE05PS ---OSS WAX 1.1 MIPS version (installed on XPNET subvol) PXSY31 - EOF 286208 06SEP2007 14:35 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 1131 06SEP2007 14:35 listing of above files PXSY323 - EOF 298496 06SEP2007 14:59 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 1131 06SEP2007 14:59 listing of above files ---OSS WAX 1.1 ITANIUM version (installed on XPNET subvol) PXSY31 - EOF 292864 06SEP2007 14:35 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 496 06SEP2007 14:35 listing of above files PXSY323 - EOF 305152 06SEP2007 14:59 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 496 06SEP2007 14:59 listing of above files Reference: Case 435114. Symptom: A Satengine process logs the following message and abends. 07-05-30;15:26:13.382 \SYS.$PPD ACI.XPSATE.3000 2 Servlet Engine is abnormally terminating (caller 150). Problem: SCR3343 (the large message scr) changed some buffer sizes leaving one buffer larger than another. This caused a buffer overrun when the larger was moved to the smaller, and variables on the stack were corrupted as a result. Change: Changed the size of buffers to be in sync with each other. Implementation: Install the new files on XPNET subvol. On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Perform the following steps to complete the installation of the new Satengine object: 1) Restore the PX* files mentioned above to a subvolume on a non-virtual disk volume. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3a) If installing on a S-Series system (non-Itanium), follow the instructions below. If installing on a NS-Series (Itanium), skip to step 3b. copy the 'sate.o' file from the temporary directory to the installation directory. Example (save the old sate.o file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/zzold Example (install the new sate.o file): > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Make the sate executable object file. Execute the appropriate make file for the NSJ version you are using. For example, if using NSJ4: > cd /user/sysaci/sysweb > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). Stop any running Satengine processes. Copy the sate object file to its runnable location: > mv -i satengine zzold (renames old satengine) > cp -p sate satengine Restart Satengine processes. 3b) If installing on NS-Series (Itanium), follow the instructions below. Stop any running Satengine processes. Copy the 'satengine' file from the temporary directory to the installation directory. Example (save the old satengine file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/satengine \ /user/sysaci/sysweb/zzold Example (install the new satengine file): > cp -p /user/temp/sysaci/sysweb/satengine \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Restart Satengine processes. Dependencies: None. SCR #3405 BASE - REL3^VER1^PROC09^20070122 30-MAY-07 - REL3^VER1^BASE^REL17^20070122 BASE - rel3^ver0^proc38^070122 - rel3^ver0^rel70^070122 GLOBAL - N31GLBL.GLBL10TG GLOBAL - n30glbl.glbl38tg NETEC - N31EMS.EMS08EC NETECOB - N31EMS.EMS08EX NETEDDL - N31EMS.EMS08ES NETETAL - N31EMS.EMS08ET NETETCL - N31EMS.EMS08EA NETTPLO - N31EMS.EMS09PO NETTPLS - N31EMS.EMS09PS NETEC - n30ems.ems27ec NETECOB - n30ems.ems27ex NETEDDL - n30ems.ems27es NETETAL - n30ems.ems27et NETETCL - n30ems.ems27ea NETTPLO - n30ems.ems33po NETTPLS - n30ems.ems33ps SATEPLO - W11SATE.SATE05PO SATEPLS - W11SATE.SATE05PS ---OSS WAX 1.1 MIPS version (installed on XPNET subvol) PXSY31 - EOF 286208 06SEP2007 14:35 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 1131 06SEP2007 14:35 listing of above files PXSY323 - EOF 298496 06SEP2007 14:59 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 1131 06SEP2007 14:59 listing of above files ---OSS WAX 1.1 ITANIUM version (installed on XPNET subvol) PXSY31 - EOF 292864 06SEP2007 14:35 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 496 06SEP2007 14:35 listing of above files PXSY323 - EOF 305152 06SEP2007 14:59 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 496 06SEP2007 14:59 listing of above files Reference: Case 436425. Symptom: XPNET 3.0 logs the following message when a Satengine process is started, and the Satengine process abends. 07-06-15;12:00:45.129 \SYS.$PPD ACI.XPNET.3000 6070 Process unknown setmode function 107 (0,-2) Problem: SCR3343 (the large message scr) added a setmode call from XNLIB to XPNET if the process supports large messages. The Satengine process was enhanced to support large messages, so XNLIB issued the new setmode on behalf of the Satengine. Since large message support was only added to XPNET 3.1, an error 2 is returned to the setmode when using XPNET 3.0 Change: Changed the Satengine so it implements large message support only if the XPNET that started it supports large messages. Also changed the Satengine to vary the size of output messages depending on the release of XPNET and whether it is configured for warm or hot backup (to eliminate multi-message checkpoints in XPNET regardless of the configuration). If the backup type is altered while the Satengine is running, the Satengine must be stopped and re-started (whether an XPNET backup is running or not doesn't change the calculation, so that never matters). Maximum output message segment size: Warm backup (all releases) : 32,000 bytes Hot backup (3.0 and older): 11,000 bytes Hot backup (3.1 and newer): 18,000 bytes Changes were made to XPNET to return the above values. If a version of XPNET is running that doesn't include these changes, or an error occurs on the attempt to retrieve them, the Satengine defaults to "no large message support" and to a max output message segment of 11,000 bytes. Satengine log event #1 was enhanced to log the values obtained from XPNET. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Perform the following steps to complete the installation of the new Satengine object: 1) Restore the PX* files mentioned above to a subvolume on a non-virtual disk volume. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3a) If installing on a S-Series system (non-Itanium), follow the instructions below. If installing on a NS-Series (Itanium), skip to step 3b. copy the 'sate.o' file from the temporary directory to the installation directory. Example (save the old sate.o file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/zzold Example (install the new sate.o file): > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Make the sate executable object file. Execute the appropriate make file for the NSJ version you are using. For example, if using NSJ4: > cd /user/sysaci/sysweb > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). Stop any running Satengine processes. Copy the sate object file to its runnable location: > mv -i satengine zzold (renames old satengine) > cp -p sate satengine Restart Satengine processes. 3b) If installing on NS-Series (Itanium), follow the instructions below. Stop any running Satengine processes. Copy the 'satengine' file from the temporary directory to the installation directory. Example (save the old satengine file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/satengine \ /user/sysaci/sysweb/zzold Example (install the new satengine file): > cp -p /user/temp/sysaci/sysweb/satengine \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Restart Satengine processes. Dependencies: None. SCR #3402 XPNET 3.0: 29-MAY-07 SKELB - rel3^ver0^sutl28^070529 rel3^scrb78^29may07 SKELLIST - sutl28tl BASE - rel3^ver0^rel71^070914 rel3^scrb78^29may07 XPNET 3.1: SKELB - rel3^ver1^sutl09^20070529 rel3^ver1^scrb02^070529 SKELLIST - sutl09tl BASE - rel3^ver1^base^rel18^20070911 rel3^ver1^scrb02^070529 Reference: Case 435247 Symptom: A SKEL-based satellite traps with code 9910 when procedure LOG^MESSAGEX calls scribe^instant^ems^interface to log a "large" event containing unprintable characters. Problem: When unprintable characters are contained in the text of a message being logged, an extra "raw data" token is added to the ems event. When a large message is being logged, the ems buffer allocated for the "emsaddtokens" call may not be large enough to hold this extra token and the text token. Change: In cases where unprintable characters are in the text, procedure scribe^instant^ems^interface was modified to calculate whether both the raw data token and the text token will fit into the ems buffer provided. If both tokens will not fit, the text token is truncated to fit as much as possible into the buffer. SKEL specific details (lengths given are aproximate): Modified the SKEL library to increase the size of the buffer passed to scribe^instant^ems^interface. This buffer is in an extended segment, not on the stack, so this shouldn't cause stack space issues. The maximum size of the text to be logged is 2800 (as before when scr scr3308 was installed). If that text contains un-printable data, and it's length is greater than 1650 bytes, the raw-data token containing the entire text is added, but the text token is truncated as needed to fit in the ems buffer (the minimum text token logged would be 500 bytes). basic calculations: 4024 maximum size of ems buffer allowed by H.P. (increased in SKEL from previous size of 3500) -724 overhead for standard tokens etc. ---- 3300 left for both the text-token and raw-data-token / 2 ---- 1650 if text is 1650, both the text token and the raw data token should fit example 1 - text is the maximum of 2800 bytes: 3300 -2800 raw data token (max allowed by SKEL) ----- 500 text token would be truncated to 500 example 2 - text is 1902 bytes: 3300 -1902 raw data token (entire text, not truncated) ----- 1398 text token would be truncated to 1398 example 3 - text is 1675 bytes (just over what will fit): 3300 -1675 raw data token (entire text, not truncated) ----- 1625 text token would be truncated to 1625 Dependencies: None. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If XPNET 3.0 and on RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3404 BASE - rel3^ver0^gate31^070110 13-JUN-07 - rel3^ver0^rel71^070914 BASE - REL3^VER1^GATE09^20070614 - REL3^VER1^BASE^REL18^20070911 Reference: Case 427257 Symptom: Service availability was not being updated in some cases between XPNET nodes which caused failures or queuing when service providers were available to process messages. Problem: If all of the service providers are dynamic (#REGISTER) and they all stop or #UNREGISTER and then restart and/or #REGISTER before the STD (Service Transmit Delay) timer expires the other XPNET nodes can get out of sync and not updated. When a service provider changes availability, the service(s) it provides are added to a transmit list with the current number available and the STD timer is added. If this is the last service provider and they are all dynamic the service is deleted from the destination table. If new messages arrive from other XPNET nodes after this they will be failed because there is no longer a destination with this name. This causes the sending XPNET to deactivate the LINK process as a provider for this service and not send any more messages with this destination to this LINK until it is notified that there are service providers available. The XPNET node that failed the messages normally keeps a flag in the destination entry for this service indicating that messages have been failed. This is done so that the external nodes are notified when the services become available again. When the STD timer expires it examines each of the services in the transmit list. If the current number available is different from the number available when it was added to the list or messages have been failed the other XPNET nodes are notified that the service is available again. The problem was caused because when the messages were failed, the destination did not exist and was not identified as a service. So the failing XPNET node did not save the fact that it needed to notify the other XPNET nodes that the service was available again if when the STD timer expired, the providers had #REGISTERed and the number available was the same so XPNET assumed nothing had really changed and there was no reason to send the notification to the other XPNET nodes. Change: Added logic to examine a message when it is failed because a destination with this name does not exist. This was addressed by SCR2989, however, there were some additional changes required to properly handle this problem. If the sending XPNET node writes a service based routed message ( msg.service^routed = true ) to our node then XPNET knows that when the STD timer expires and the service is available the other XPNET nodes must be notified. This was done by adding a flag to the entry for this service in the transmit list. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3413 BASE - rel3^ver0^proc39^070829 19-SEP-07 - rel3^ver0^rel71^070914 BASE - REL3^VER1^PROC10^20070918 - REL3^VER1^BASE^REL18^20070911 Reference: Case 438861 Symptom: - XPNET Node dumps with a 6410 Problem: A message with the broadcast bit was routed to an external XPNET node which failed it with a 110. The originating XPNET node interpreted this as a routing error and rerouted the message to find a contigency object. When this occurs, because the broadcast bit is on, the message is duplicated and both messages are sent back across the link process and failed again. Each time this occurs, the number of messages double. This cycle continued until the originating node ran out of memory. The remote XPNET node is supposed to drop the broadcast message if it does not have a local object or service the message was routed to. However, there is a scenario which caused the message to be failed instead. If the remote node had an external destination with the same name as the symbolic dest in the broadcast message which is routing to a third XPNET Node, the message was failed instead of dropped. Change: Changed the logic in the originating XPNET node to examine the failed message before rerouting it. If the message failure is 110, came from a link process and the broadcast bit in the message header is true, the message is dropped instead of rerouting it. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3414 BASE - rel3^ver0^proc39^070829 21-SEP-07 - rel3^ver0^rel71^070914 BASE - REL3^VER1^PROC10^20070918 - REL3^VER1^BASE^REL18^20070911 Reference: Case 443017 Symptom: - Dynamic service registration fails YY-MM-DD;HH:MM:SS.hhh \SYS1.$P1AN ACI.XPNET.3100 6331 Add Service failed, conflicts with Destination routing to EXTERNAL , sym type SERVICE - ALTER PROCESS , SERVICE fails Process service failed, obj name conflicts with an ext dest. - Adapted entries added into destination table for services. For example: AKDSIS AKDSIS!!!!!!!!!! AKSSIS"""""""""" AKDSIS########## Problem: When a message is read from a LINK process, the symbolic source of the message is used to search the internal destination table. If the symbolic name is found and the (external) dest entry for this name is routing to the link process the message was read from, nothing further is done and the message is routed on to its destination. If the symbolic source of the message is not in the table, it is added as an external destination routing to the link process the message was read from. It is assumed that a response will be sent back to this source so XPNET automatically adds the return path. This avoids the delay and overhead of having to issue a DISCOVER request when the first response is routed. It also avoids potential routing errors if more than one object with this name is configured for contingency. A DISCOVER could potentially find a different copy of the object and route the response back to the wrong source process. This is also done to support adaptive routing. If the source name exists, but is routing to a local object, service or different link process, the source in the message is modified using the adaptive routing algorithm (the trailing spaces are changed to one of 15 special characters) and a unique entry with this new adapted source is added to the routing table. So as long as the destination routes the response back to the adapted source, the message will be routed to the correct source object on the correct XPNET node. The problem occurs because this logic did not account for a service name in symbolic source of the message. There was a timing window that allowed this problem to occur. The application processes that provided the service were abending and restarting. If the service is dynamic, when the last service provider stops or unregisters, the service name will removed from the destination table. If a message with the service name in the symbolic source is read from a link process before the service is registered, an external dest will be added into the destination table with this name. Once this occurs, a service with this name can not be registered or altered on that XPNET until the external destination is removed. If the symbolic source is a service and the service does exist in the destination table, it will not be directly routing the link process which causes the adaptive routing to be invoked. This logic was not designed to work with a service specified in the message symbolic source. Change: Changed the logic that determines if an external dest should be added for the source of the message. If msg^sym^type^source = service^l then do not add an external dest for the return path. Changed the adaptive routing logic to not modify the source and add the adapted name in the destination table if the source name is a service. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3415 XPNET 3.0: 29-MAY-07 SKELB - rel3^ver0^sutl28^070529 SKELLIST - sutl28tl XPNET 3.1: SKELB - rel3^ver1^sutl09^20070529 SKELLIST - sutl09tl Reference: Case 438190 Symptom: - A SKEL based Satellite abends when using AUTOTMF in procedure F^L^^NFO - A sample of the stack trace follows Num Lang Location ABEND 0 TAL #F^L^^NFO.#1966(SRTINFO) 1 TAL #FILEERROR.#2549(SUTL26TS) 2 TAL #RTMONC^OPEN^MONITOR^NOWAIT.#323(SRTMONC) + %11I 3 TAL #RTINIT^INITIALIZE^ESGPTR.#2710(SRTINIT) + %10I 4 TAL #ARMTR^P.#720(SRTSTOP) + %1I 5 TAL #TRAP^DUMP.#1472(DLIBB6CS) 6 TAL #TRAP^DUMP^.#8622(BAUTILS) 7 TAL #AUTHS^PK^04.#2977(AUTHS) Problem: SKEL contains a procedure named FILEERROR which replaces the Guardian procedure of that same name in SKEL based Satellite applications. The Guardian procedure allows the high order bit of the file number to be set indicating that messages should not be logged to hometerm. The SKEL based FILEERROR procedure does not implement this functionality, therefore attempts to use negative values for the file number. Change: Changed SKEL procedure FILEERROR to deal with file numbers whose high order bit is on. File number %137777 is treated as %177777 (-1), the high order bit is ignored for all other file numbers. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3418 BASE - REL3^VER1^BASE^REL19^20071031 11-OCT-07 - REL3^VER1^PROC11^20071023 - REL3^VER1^GATE10^20071008 - REL3^VER1^EXEC10^20070505 - REL3^VER1^ONCF^CJ04^20071025 - REL3^VER1^ONCF^STA07^20071025 - REL3^VER1^ONCF^SYS12^20071025 CTS - REL3^VER1^CTS06^20070522 GLOBAL - N31GLBL.GLBL11TG NETEC - N31EMS.EMS09EC NETECOB - N31EMS.EMS09EX NETEDDL - N31EMS.EMS09ES NETETAL - N31EMS.EMS09ET NETETCL - N31EMS.EMS09EA NETTPLO - N31EMS.EMS10PO NETTPLS - N31EMS.EMS10PS NETDDLS - N31GLBL.GDDL04DS NETDC - N31GLBL.GDDL04DC NETDTAL - N31GLBL.GDDL04DT NETDFUP - N31GLBL.GDDL04DZ DDLC - S31SDDL.SDDL05DC DDLCOB - S31SDDL.SDDL05DX DDLFUP - S31SDDL.SDDL05DZ DDLS - S31SDDL.SDDL05DS DDLTAL - S31SDDL.SDDL05DT NCPDC - S31NCPI.NCPI09DC NCPDCOB - S31NCPI.NCPI09DX NCPDCB74 - S31NCPI.NCPI09DV NCPDDDL - S31NCPI.NCPI09DS NCPDFUP - S31NCPI.NCPI09DZ NCPDTAL - S31NCPI.NCPI09DT NCPDTCL - S31NCPI.NCPI09DA NCPCOM - REL3^VER1^NCPC18^20071025 - REL3^VER1^NCPL16^20071025 - REL3^VER1^RLBK03^20071025 SVNCS - REL3^VER1^SNCS15^20071025 - REL3^VER1^NCPL16^20071025 SVNCPI - REL3^VER1^REL15^20071025 - REL3^VER1^NCP13^20071025 - REL3^VER1^OBJ10^20071025 - REL3^VER1^RN09^20071015 SVNCSP - SVNCSP-31-08 - SVTAB-A-31-06 NCSPREPT - NCSP-REPORT-REL31-06 SVNCSP24 - SVNCSP-NET24-31-08 SVTAB-A-31-06 NETCJRD - REL3^VER1^CJRP04^071025 Reference: Work Order # 070731-01 Symptom: Dynamic Duplicate XPNET station configuration enhancement. This enhancement offers the capability for configuration of duplicate available TCP/IP STATION entries in a single XPNET network. Problem: Without this enhancement it is possible to configure STATIONs with the same name within an XPNET network, but in one case this will result in routing inconsistencies and in the other case the failover to use the alternate STATION requires a significant multi-step operator intervention. Change: This enhancement enables this processing to be automated, such that there can be a separate TCPSRV process with duplicated STATIONs in the STARTING state; XPNET will be responsible for managing the routing of traffic to either the 'primary' or 'alternate' STATION based upon the last connection that has been established. The 'primary' station will be added to the dest table as a local station and will be initially used to route messages to. The 'alternate' station will be added to the dest table as an external station routing to the partner link. Both stations are still enabled and can altered, started, status, etc from ONCF, however, from a routing standpoint there is only one station. Both stations will be in the starting state and the first station to transition to started will be the station that will be where messages are routed to. If the station is already in the dest table as a local station, nothing needs to be done. If the partner station currently in the dest table is an external station, it is changed to route to the local station and a 'destupdate' message is sent to all of the other XPNET nodes it is connected to including the partner node. If the XPNET node is the partner node the station is changed from routing to the local station to an external dest routing to the partner link. The other XPNET nodes will update their dest entry to point at the link process the destupdate message was read from. The routing can be verified using the following command. This will show what each XPNET node DEST entry for the partner station is routing to. STATUS DEST , DETAIL Implementation: Install the new object/template files on the XPNET subvol. Rebuild the NETWORK object with new BASE and CTS modules using the NETB file. Stop all the NCPI servers from TACL. Freeze/Stop/Thaw SVNCS and SVNCSP. If security is enabled, update the appropriate NCSP records. All XPNET nodes should restarted with the new network object file at the same time. Configure two stations with the same symbolic name on two XPNET nodes linked together, one with a ROUTETYPE of PRIMARY and one ALTERNATE. Each one needs to have a PARTNERLINK set to the local link process connected to the XPNET node with the duplicate configured. \SYS1.P1A^NODE.S1^ATM^01 ROUTETYPE PRIMARY PARTNERLINK P1A^LINK^P1B \SYS1.P1B^NODE.S1^ATM^01 ROUTETYPE ALTERNATE PARTNERLINK P1B^LINK^P1A On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.1 Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. For detailed information request internal specification for XPNET work order #070731-01 from Help24. Dependencies: CTS version (REL3^VER1^CTS06^20070522) should be installed with BASE (REL3^VER1^BASE^REL19^20071031) or greater. If not XPNET may generate undefined externals for procedures DEST^SWITCH^ROUTING^INFO and DEST^SEND^DESTUPDATE^MESSAGE. This will not cause any problems, however, this enhancement will not work. SCR #3422 15-DEC-07 ---XPNET 3.1 BASE - REL3^VER1^BASE^REL19^20071031 - rel3_ver1_payl_rel07_071215 - rel3_ver1_payl05_071215 PAYLLIB - rel3_ver1_payl_rel07_071215 - rel3_ver1_payl05_071215 ---XNLIB 3.1 XNLIBN.XNLIB - rel3_ver1_xnlib_rel23_071215 REL3_VER1_PAYL_REL07_071215 REL3_VER1_PAYL05_071215 XNLIBN.XNLIBN - same as XNLIB, above XNLIBN.XNLIBR - same as XNLIB, above XNLIBN.XNLIBEN - same as XNLIB, above XNLIBN.XNLIBER - same as XNLIB, above Reference: Case #444561 Symptom: 108 Misalginment error message. Problem: Payl code accesses an integer in the payload key token structure that is not on a word boundary. The PK token is placed into XPNET msg userdata. XPNET msg userdata is always at a word boundary. If the PK token is placed at the beginning of XPNET msg userdata the PK token structure is correctly designed to have any integer on a word boundary. If an application adds data to XPNET msg userdata and moves the PK token such that the PK token begins on a odd byte boundary, when the length field is accessed the misalignment error is logged. Change: Code was changed to move the PK token into a local buffer when accessing the length field. This ensures that PK token begins on the word byte boundary. Implementation: Since XNLIB and APPLIB can be ran as user libraries, do the following only after taking appropriate action to avoid library conflicts. Install the new XPNET files on the XPNET subvolume. On the XPNET subvolume, rebind the NETWORK object using the NETB file. Install the new XNLIB files on the XNLIB subvolume. If the customer uses the APPLIB library, it should be rebuilt using the APPLIBBC and APPLIBB files to include the modified PAYLLIB library. Follow the directions in APPLIBB for completing this process. The resulting APPLIB object can be renamed to SKELB if desired. If on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. APPLIB may also be accelerated separately by obeying the APPLAXCL file. The non-native XNLIB library object can be accelerated using the XNLIB.XNAXCL obey file. If using an Itanium NonStop machine (NS-Series), accelerate appropriate files using the following OCA macros: - XPNET.OCAAPPL (for XPNET.APPLIB, if rebuilt) - XPNET.OCANLIB (for XPNET.NETLIB) - XNLIB.OCAXNLIB (for XNLIB.XNLIB) Application processes which use APPLIB or XNLIB as a run-time library must be stopped and restarted in order for the new library to take effect. Application processes which bind one of the above libraries must be re-compiled or re-bound with the new library. SCR #3424 NCPCOM - rel3^ver1^ncpc18^20071025 11-DEC-07 rel3^ver1^ncpl16^20071025 SVNCS - rel3^ver1^sncs15^20071025 rel3^ver1^ncpl16^20071025 SVNCPI - rel3^ver1^rel15^20071025 rel3^ver1^obj10^20071025 BASE - REL3^VER1^BASE^REL19^20071031 REL3^VER1^ONCF^STA07^20071025 Reference: Case 450248 Symptom: - ADD STATION fails with invalid QMI attribute. - SET STA RADDR command corrupts other station attributes. - SHOW STA command shows invalid data for CLASS, SOURCECLASS, QMI, and CONNSPEC attributes. RADDR contains blanks. - RADDR is truncated when issuing the INFO STA,OBEYFORM command. Problem: In 3.1, new LADDR and RADDR station attributes were added to support 56 characters. The SHOW command, OBEYFORM modifier and the ADD command were not changed to reference the 56 character data field. The SET RADDR and SET LADDR commands moved 56 characters to the old 24 character fields overlaying other attributes with data from the SET command. The ALTER and INFO,DETAIL and STATUS commands referenced the correct data fields. Change: Corrected the processing of the SET RADDR and LADDR commands to update the new 56 character fields, corrected the SHOW and OBEYFORM modifier to display the new fields, and updated the net work station ADD routine to use the new fields for 3.1 ONCF ADD commands and the old 24 character fields for 3.0 ONCF add commands. Implementation: Install the new object files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop all the NCPI servers from TACL. Freeze/Stop/Thaw SVNCS and SVNCSP. Stop and restart NCPCOM. Dependencies: XPNET 3.1 only SCR #3441 BASE - REL3^VER1^BASE^REL20^20080622 16-JUN-08 - REL3^VER1^NSTP06^20080622 - REL3^VER1^EXEC11^20080622 - REL3^VER1^ONCF^SYS13^20080616 - $data01.l10llib.lsec04ts LIVERIFY - T0000D45_16JUN08_LCNS10_LVFY04 Reference: Case 468479 Symptom: - Validation Error 11 on license file : required procedure not found. Problem: The licensing code validates a number of system procs using a specific memory address. The address for these procedures has changed with the Blade technology which caused the verification to fail and not pass the XPNET license validation process. Change: Modified the licensing code so the system proc validation does not fail. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.1 Only. SCR #3442 --XPNET 3.0 22-Jun-08 BASE - rel3^ver0^rel73^080622 - rel3^ver0^nstp19^080622 - rel3^ver0^exec31^080622 GLOBAL - n30glbl.glbl39tg PLU - rel3^ver0^plu10^080622 SLU - rel3^ver0^slu12^080622 --XPNET 3.1 BASE - REL3^VER1^BASE^REL20^20080622 - REL3^VER1^NSTP06^20080622 - REL3^VER1^EXEC11^20080622 GLOBAL - N31GLBL.GLBL12TG PLU - REL3^VER1^PLU03^20080622 SLU - REL3^VER1^SLU04^20080622 Reference: Case 462448 Symptom: - After a CPU failure or a SWITCH command, a message is not sent on a PLU or SLU station until an inbound message is received. - Messages queue on PLU or SLU stations and are sent one at a time for each inbound message received. Problem: After a backup takeover, SETMODE 30 to allow I/O's to complete in any order was not re-issued. This problem was introduced by SCR 3068, that scr changed PLU and SLU to do no-waited opens. The manner in which XPENT dispatches the tag passed to open on a backup takeover is different for files opened waited and no-waited, so the protocols were not informed about the takeover and did not re-issue SETMODE 30. After a takeover, when PLU or SLU issued a SEND-DATA, it would not complete until a RECEIVE-DATA completed. When the RECEIVE-DATA completed another SEND-DATA could be initiated, but it would not complete until the next RECEIVE-DATA completed (and so on). Change: Changed the way IO tags are dispatched on backup takeover for files doing no-waited opens. A new option was added to open^ and fes_file_open_ that allows the user to select this new functionality, otherwise it works as before. For now the PLU and SLU protocols are the only modules using this new functionality. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3439 CTS - rel3^ver0^cts29^080611 06-APR-08 CTS - rel3^ver1^cts07^20080611 Reference: Cases 464694, 467811 Symptom: - The "MSGS PENDING" count on the statistics line detail response grows. - The Network process abends with trap number 6205 when an error occurs on a CTS line. Problem: When a message is about to be written from the CTS protocol, lin.cnt^pending (MSGS PENDING) is incremented. This is done before checking if the connection ID is invalid, which will cause the message to be failed with failure 109. Normally lin.cnt^pending would be decremented when the write completes, but since the write is not initiated when failure 109 occurs, the count grows by one for each such failure. If enough failure 109's occur during the life of the Network process, lin.cnt^pending can become negative. If a write is pending and an error occurs, the Network can abend with trap number 6205 since it doesn't expect this count to be negative at that time. Change: This problem was introduced by SCR 2581 when the code to increment lin.cnt^pending was moved along with surrounding code to correct a problem. The one line of code that increments lin.cnt^pending was moved back to its' original position. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. If XPNET 3.0 and on RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3446 SVNCPI - rel3^ver0^ncp34^07302008 30-Jul-08 rel3^ver0^rel37^07302008 SVNCPI - rel3^ver1^ncp14^20080730 rel3^ver1^rel16^20080730 Reference: Case 472007 Symptom: A "TELL" command destined for a PPD that is not running resulted in an inacurrate "node not avail" response. Problem: NCP response was being set to ncp-err-node-not-avail. Change: Modified the logic to return ncp-err-obj-not-found versus ncp-err-node-not-avail. Implementation: Install the new object on the XPNET subvol. Stop all the NCPI servers from TACL. Dependencies: None. SCR #3447 CTS - rel3^ver1^cts08^20080815 06-AUG-08 Reference: Case #471665 Symptom: IMN software tries to start XPNET TCPIP Client stations programatically with control messages. TCPCLI and XPNET log messages indicating a 4115 EADDRNOTAVAIL error occurred. Station does not go started. Problem: CTS is not filling in the new CTS_REMOTE_ADDR and CTS_LOCAL_ADDR fields in the ALLOC CONN request to the TCPCLI process for control messages. TCPLCI then uses the default of 0.0.0.0 for the remote address. Change: Changed CTS code to fill in the CTS_REMOTE_ADDR and CTS_LOCAL_ADDR fields in the ALLOC CONN request to the TCPCLI process for control messages. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3454 NCPCOM - REL3^VER1^NCPC18^20071025 10-OCT-08 REL3^VER1^NCPL17^20081001 SVNCS - REL3^VER1^SNCS15^20071025 REL3^VER1^NCPL17^20081001 NETCJRD - REL3^VER1^CJRP04^071025 Reference: Case 478158 Symptom: - NCPCOM INFO with OBEYFORM returns "STAABNORMAL OFF" if STAAVAIL has been set to "OFF" - NCPCOM INFO with OBEYFORM returns "STAABNORMAL OFF" if STACONFIG has been set to "OFF" Problem: Text returned if STAAVAIL and/or STACONFIG are set to OFF was "STAABNORMAL OFF". Change: Altered code so text returned if STAAVAIL is OFF is "STAAVAIL OFF". Altered code so text returned if STACONFIG is OFF is "STACONFIG OFF". Implementation: Stop server-ncs. Replace existing NCPCOM, server-ncs, and NETCJRD objects. No system outage is necessary for this change. Dependencies: None. SCR #3455 XNCGEN - REL3_VER1_XNCG07_20081030 30-OCT-08 Reference: Case #477443 Symptom: Problems with starting Xpnet 3.1 when trying to add more than 40 external processes are configured. The external processes are TCPCLI and TCPSRV only. When trying to start up XPNET, it seems to go into suspended state, and the backup process is not created. Problem: The code added the current End Of Segment with the amount of memory needed when it determined it had to increase the size of the segment. It should have added the Actual End Of Segment to the amount of memory needed to ensure that any adjustments for aligning on word boundaries were accounted for. The code had to adjust the structure being referenced to line up on a word boundary. This adjust was not accounted for in the resize. Change: Added code to resize the segment by chunks of 32K bytes. This will eliminate multiple resize calls once the original segment size is exceeded. This will also eliminate the possibility that a small discrepancy in Current End of Segment/Actual End of Segment and a referenced structure could point past the Actual End of Segment. Implementation: Install new XNCGEN object file. Dependencies: XPNET 3.1 only. SCR #3440 XPNET 3.0/3.1 01-DEC-08 SKELB - rel3^ver0^sutl29^20081201 - rel3^scrb79^20081201 SKELLIST - sutl29tl SKELB - rel3^ver1^sutl10^20081201 - rel3^ver1^scrb03^20081201 SKELLIST - sutl10tl DDLC - S30SDDL.SDDL16DC DDLCOB - S30SDDL.SDDL16DX DDLFUP - S30SDDL.SDDL16DZ DDLS - S30SDDL.SDDL16DS DDLTAL - S30SDDL.SDDL16DT DDLC - S31SDDL.SDDL06DC DDLCOB - S31SDDL.SDDL06DX DDLFUP - S31SDDL.SDDL06DZ DDLS - S31SDDL.SDDL06DS DDLTAL - S31SDDL.SDDL06DT 3.0 POBJ T3270-LMCF (D30) 15 NOV 2008 17:01:43 T3270-LMCF-NO-PCI (D30) 15 NOV 2008 16:38:06 T3270-LMCF-PCI (D30) 15 NOV 2008 16:56: T6520-LMCF (D30) 15 NOV 2008 17:01:33 T6520-LMCF-NO-PCI (D30) 15 NOV 2008 16:37:51 T6520-LMCF-PCI (D30) 15 NOV 2008 16:55:57 3.1 POBJ T3270-LMCF (D30) 15 NOV 2008 17:16:52 T3270-LMCF-NO-PCI (D30) 15 NOV 2008 16:45:55 T3270-LMCF-PCI (D30) 15 NOV 2008 17:10:36 T6520-LMCF (D30) 15 NOV 2008 17:16:43 T6520-LMCF-NO-PCI (D30) 15 NOV 2008 16:45:39 T6520-LMCF-PCI (D30) 15 NOV 2008 17:10:18 SVLMCP - NET24-LMCF-PCI-SERV-30 SVLMCV - BASE24-LMCF-PCI-INFO-30. SVLMCP - NET24-LMCF-PCI-SERV-31 SVLMCV - BASE24-LMCF-PCI-INFO-31. Reference: wo 070104-03/080415-03 Symptom: None - this is an enhancement The purpose of this enhancement is to mask or otherwise alter EMS messages that are generated by satellite code via SKEL. With this change messages can be configured so that sensitive user data is not visible. This conforms to the Payment Card Industry (PCI) Data Security Standards and is supported using modifications to the LMCF screen and SKEL library. Problem: None Change: Added three new requesters and two servers: T6520-LMCF (SVLMCV), T6520-LMCF-NO-PCI (SVLMCF) T6520-LMCF-PCI (SVLMCP). The new T6520-LMCF decides whether the LMCF being read is old or pci-format. Old LMCF format records will be processed by the T6520-LMCF-NO-PCI requester which is a renamed copy of the old LMCF requester working with the existing LMCF server object. PCI formatted LMCFs will be processed by the T6520-LMCF-PCI req/srv pair. SKEL has been changed to work with either format LMCF. Eeach message a satellite generates can now be masked or truncated based on configuration settings in the PCI LMCF. Implementation: SCUP COPY three requesters T6520-LMCF, T6520-LMCF-NO-PCI, T6520-LMCF-PCI to your working POBJ. Copy the two server objects: SVLMCV and SVLMCP to your working object subvolume. Add new Pathway entries for SERVER-LMCF-VSN (SVLMCV) and SERVER-LMCF-PCI (SVLMCP ). The existing SERVER-LMCF definition will remain unchanged and will use the exiting SVLMCF object Copy the new SKELB object to your production location. This should NOT require a recompile of any satellite. (Unless SKELB is bound into your object - not BASE24 standard). Use the existing LMCF file if you are not ready to implement PCI masking. Otherwise, create a new LMCF file using the XPNET.DDLFUP file. More complete instructions are provided in the BASE24 Release 6.0 Version 9 Implementation Guide. See also section 1 of the BASE24 Event Message Reference Manual, version 9, for a description of the LMCF screen changes. Dependencies: The new requester server pairs and SKEL should be implemented together. A pre-PCI LMCF file may be used with the new requester/server pairs and SKEL but PCI masking will not occur until a new format LMCF is configured. NOTE: The SKEL code is backward compatible with older versions of the network and the LMCF data file. If any of the components of this change are left out (LMCF requester/server code or PCI-formatted LMCF file) this code will display satellite messages without PCI masking or truncation. SCR #3453 SKEL - rel3^ver1^sutl10^20080901 25-SEP-08 rel3^ver0^sutl29^080211 Reference: Clarify case 477258 Symptom: - Sixteen digit PANs within 64500000 - 64999999 range are Discover cards - SKEL did not recognize PANs within the 64500000 - 64999999 range as Discover cards Problem: Discover PAN range of "64400000" - "64999999" was incorrectly developed as "64400000" - "64499999". Change: Corrected sixteen digit Discover PAN range to be "64400000" - "64999999". Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. Dependencies: None. SCR #3426 BASE - rel3^ver1^gate11^20071220 13-AUG-08 - rel3^ver1^base^rel21^20080813 Reference: Cases 451198, 473683 Symptom: - SIGNUM 11 trap in DEST^GROW^TREE. Problem: When the dest tree becomes full, a new larger dest tree (150% of previous table) is allocated and the old table is copied into to it. The XPNET 3.1 enhancement to support the DEST object changed the logic that increased the size of the table and inadvertantly passed the wrong address for the new table which caused the trap. Change: Changed the logic in DEST^GROW^TREE to pass the correct address of the new dest table. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: None. SCR #3448 BASE - REL3^VER1^PROC12^20080813 13-AUG-08 - REL3^VER1^BASE^REL21^20080813 Reference: Case #459223 Symptom: External process starts and then fails with no error message generated. Problem: If the XNCALIAS cannot be found in the XNCONF file configured under the DEVICE then the process will start but then fail. XPNET logs event 6399 when it detects this configuration error, but this was only generated once when the process is added or when the XPNET node starts, but NOT after that when the process is started. Change: Changed XPNET to also generate EMS event 6399 every time the process is started if this configuration error exists. 08-08-13;09:53:02.631 \PROD.$P1CN ACI.XPNET.3100 6399 Symbolic name P1C^TCP^ALIAS (P1C^TCPSRV01) not in XNC \PROD.$DATA.P1AXNC.XNCA0 configured in DEVICE D1C^PRO1 Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3450 BASE - REL3^VER1^PROC12^20080813 13-AUG-08 - REL3^VER1^BASE^REL21^20080813 Reference: Case #469852 Symptom: Message failure 110 when routing to a valid external destination. Problem: Request message header reused for response message and MSG^EXTERNAL^SOURCE was not reset before sending to XPNET. When a message is routed over a LINK process, there is a bit set in the message header to indicate that the message originated on another XPNET node. The reason this is done is to prevent this message from being routed to a third XPNET node from the second XPNET node. We never make more than one node hop at a time. If the message needs to be routed to a third node, it must be failed back to its originating node and rerouted from that node to a third node. This is to avoid routing errors in order to prevent messages from getting in a loop routing to multiple resource nodes. There is also the possibility that the third XPNET node may not have a LINK process connected to the first node, preventing the response from finding its way back to the originating XPNET node. If this bit is set on and the message is routed to an external destination, the message is failed back to its source with a failure 110. Change: Added logic to reset MSG^EXTERNAL^SOURCE on all input messages that are not read from a LINK process. This will prevent the failure 110 if the application process reuses the request message header, does not reset this bit and routes the response message to a destination on another XPNET node. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3451 BASE - REL3^VER1^BASE^REL21^20080813 11-SEP-08 REL3^VER1^ELOG03^20080911 Reference: Case #474456. Symptom: - Station unavailabe event is not generated when set to ON and NDF set to OFF. Problem: The station unavailable event procedure does not correctly check the event flag. It would only return TRUE when the object level equaled NODE and the node level equaled ON. Change: Corrected the logic to check the NODE level and object level flags. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3459 BASE - REL3^VER1^ONCF^SYS14^20081029 29-OCT-08 - REL3^VER1^BASE^REL21^20080813 Reference: Case #453489 Symptom: They could not get stations to connect. They kept getting message failure 110's returned to the station for messages routed to station destination following ONCF command: CONTROL NODE , DESTDELETE * UNDER LINK They issued a CONTROL NODE , DESTADD and CONTROL NODE , DESTDISCOVER command, still same issue. Finally they did a set like the process then deleted it and readded it and things started working again. Problem: The logic that performs the CONTROL NODE , DESTDELETE * UNDER LINK did not validate that the passed in the UNDER LINK parameter was actually a LINK PROCESS. If a local process or station was inadvertanly entered instead of a link, that symbolic name was deleted from the routing table which in turn caused the routing errors to occur. CONTROL NODE , DESTDELETE * UNDER LINK was intended to only delete EXTERNAL routing destinations. Change: Added logic to validate the symbolic name passed in UNDER LINK is a LINK process before updating the routing table. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: XPNET 3.1 only. SCR #3474 SVNCPI - rel3^ver0^rel38^02062009 13-FEB-09 rel3^ver0^ncp35^02062009 SVNCPI - rel3^ver1^rel17^20090206 rel3^ver1^ncp15^20090206 Reference: Case 472366 Symptom: A "TELL EXTERNAL" command causes SVNCPI to loop and emit the following EMS event when in running without a backup: NCPI CHECKPOINTMANYX failed, status 1, error 201 Problem: The open completion logic set the RN structure address to zero. The RN.checkpoint^required test results in a loop calling the checkpoint backup routine. This would cause the event to be created in the case when there is no backup or increased cpu busy if running with a backup. Change: Reset the RN pointer to the global RN pointer if the RN lookup sets the RN pointer to zero. Implementation: Install the new object on the XPNET subvol. Stop all the NCPI servers from TACL. Dependencies: None. SCR #3473 OCAMQSI - $data01.n30mqsi.oca00as 28-JAN-09 OCAALL - $data01.u30oca.ocaa01as MQSIAXCL - $data01.n30mqsi.goax00 OCAMQSI - $data01.n31mqsi.oca00as OCAALL - $data01.u31oca.ocaa01as MQSIAXCL - $data01.n31mqsi.goax00 Reference: 487144 Symptom: - No OCA file available for MQSI - No AXCL file available for MQSI Problem: The XPNET 3.0 and 3.1 MQSI objects were overlooked when developing OCA (Object Code Accelerator) TACL routines to accelerate code 100 object files. An acceleration file was previously not available for MQSI running on a K-series or S-series system. Change: Developed OCAMQSI TACL routine for XPNET 3.0 and XPNET 3.1. Altered OCAALL files for XPNET 3.0 and XPNET 3.1 to include the OCAMQSI file. Created a MQSIAXCL file for XPNET 3.0 and XPNET 3.1. Implementation: Restore the OCAALL to the XPNET subvolume. Restore the OCAMQSI file to the XPNET subvolume. Restore the MQSIAXCL file to the XPNET subvolume. Bind the MQSIO object with the IBM Websphere MQ API library. Run the OCAMQSI TACL routine to accelerate the MQSI object for Nonstop Integrity NS-series systems. Run the MQSIAXCL TACL routine to accelerate the MQSI object for Nonstop Himalaya K-series or S-series systems. Dependencies: None SCR #3468 BASE - REL3^VER1^PROC13^20081215 15-DEC-08 - REL3^VER1^ONCF^PRO10^20081215 - REL3^VER1^BASE^REL22^20081215 GLOBAL - N31GLBL.GLBL13TG Reference: Case #460784 Symptom: - After a CPU failure, non-stop external processes (like TCPCLI and TCPSRV) that are running in the failed CPU go into the abnormal state. - The processes are still running, but have reverted to their backup process. The processes must be stopped from TACL to get them back into the proper state. Problem: When a Satellite process opens XPNET, the process handle is saved. If the process has a backup, a checkopen of XPNET would cause it to save the backup's process handle. These process handles are used to determine the state of a process when certain events occur, including a CPU failure. At initialization an "Internal Satellite" calls NETINIT (SKEL) or NETLIB_INIT (NETLIB). These utilities open XPNET on behalf of the process. Since "External processes" do not call NETINIT or NETLIB_INIT, XPNET is not opened, thus the phandle is not saved. A non-stop Internal Satellite would need to checkopen XPNET in order for the backup phandle to be maintained. SKEL and NETLIB do not do checkopens, so NonStop Internal Satellites are not supported and would have problems similar to those mentioned for External Processes in the symptom above. The only know non-stop Internal Satellite to exist is External Gateway, which was written by ACI and did not use standard SKEL (it did it's own checkopens). External Gateway has not been supported for years, so NonStop Internal Satellite support is no longer required. Change: For External Processes, XPNET was changed to look up the necessary primary and/or backup phandle's at the point they are needed based on the configured PPD name (rather than expecting to have it saved from open time). The PPD name is now REQUIRED when configuring an External Process. It is assumed PPD names were configured in the past since things like TCPSRV, TCPCLI, and HLS need to be named, but you should verify this and configure PPD names for all External Processes. For external processes, the saved phandle will contain the actual process handle only during initial startup. After startup it is updated with special values for internal XPNET use, and the actual phandles are looked up when needed as described above. NonStop external processes are supported. No change was made in the way Internal Satellite processes work. NonStop Internal Satellite processes are not supported, but persistent Internal Satellite processes can be maintained with the proper "startup" parameter setting. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: XPNET 3.1 only. SCR #3475 BASE - REL3^VER1^EXEC12^20081211 17-FEB-09 - REL3^VER1^BASE^REL22^20081215 Reference: Case #471427 Symptom: XPNET abnormally terminates with trap 6883 in procedure COMPARE^MEMORY^COPY^TO^NEF after an ALTER PROCESS command was executed. Problem: Previously an ENABLE PROCESS command was executed on this process which was already enabled. The command fails as it should, however, the logic assumed that the object was DISABLED prior to the command failing and sets the pro.disabled flag to true without updating the NEF. This causes the information in the NEF and the memory copy of the process to become out of sync. Once this occurs, the next time a valid ALTER command is done [could be days later] on this object, the compare of the memory copy process information and the NEF process information will not match and cause trap 6883. This compare logic was added to prevent XPNET from corrupting the NEF if the memory copy has bad data in it. If the NEF becomes corrupted, a PURGEDATA may have to be done and all of the configuration data would have to be added back manually. If the latest configuration information had not been saved ( INFO /out /, OBEYFORM ), it could very difficult to restore the data in the NEF. In order to prevent this, before XPNET updates the NEF, it compares the data and dumps if there is a difference to protect the NEF. This problem exists for the ENABLE PROCESS, DEST and NODE commands. Change: Changed the ENABLE PROCESS, NODE and DEST logic to validate the object is disabled before executing the command. If the object is enabled, the command will fail with "obj already in state" and the disabled flag is not updated. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: XPNET 3.1 only. SCR #3476 BASE - REL3^VER1^EXEC12^20081211 17-FEB-09 - REL3^VER1^BASE^REL22^20081215 Reference: Internal Symptom: Automatic process does not start after ENABLE command without operator intervention. Problem: If the process had been aborted or failed more than RETRIES number of times prior to being disabled, the process did not restart after it was enabled. The internal flags (fail^ctr and autostart^disabled) were not properly reset. This prevents an automatic process from starting without operator intervention when it is enabled. Change: Added logic to reset flags autostart^disabled and fail^ctr when the ENABLE command is successfully executed. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: XPNET 3.1 only. SCR #3362 CTSE - rel3_ver1_ctse03_090330 30-MAR-09 CTSEPLO - $data01.n31ctse.ctse04po CTSEPLS - $data01.n31ctse.ctse04ps Reference: Case #401567 Symptom: The following is logged by EMSPERUS: ERROR: EMSTEXT FAILED ON ATTEMPT TO PRODUCE TEXT FOR EVENT UPPER WORD OF ERROR VALUE IS 12 LOWER WORD OF ERROR VALUE IS 14 05-10-04;11:35:02.790 \K9.$SRV ACI.XPCTSE.3000 1008 Backup process ? created. Problem: CTSE logs the above messaage with the xpctse-tkn-phandle token. This token instructs EMS to resolve the PHANDLE to a printable form to log. If the process is no longer running when EMS attempts to resolve the PHANDLE an error occurs and the above error is logged. Change: Changed the code to resolve the phandle to a string and log the message using the xpctse-tkn-char-var token. EMS will now store the PPD name of the process and can log message 1008 when the process no longer exists without the error. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: At least the following levels of CTSE bound into the object. rel3_ver0_ctse19_061030 rel3_ver1_ctse03_090330 SCR #3486 SKEL - rel3^ver1^sutl11^20090430 30-APR-09 - rel3^ver0^sutl30^20090430 Reference: Case #495955 Symptom: SKEL code was not suppressing messages that had LMCF severity code of 9 (suppress). Problem: NUMIN requires that any data passed is terminated with a zero. When SKEL passed the LMCF SEVERITY code to NUMIN the data was not delimited. NUMIN would then attempt to convert the lmcf severity and any data up to the first zero. i.e. if the next byte in lmcf record was not a zero numin would fail. The code would then default the severity code to 2 (error). This problem meant that the severity code was almost always being defaulted to 2 (error). These are the possible values for LMCF severity: 0 = Information 1 = Warning 2 = Error 3 = Critical 9 = Suppress Change: Moved severity into a temporary buffer that was terminated with a zero. Passed this buffer to NUMIN for processing. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. SCR #3470 POBJDIR - CDF-REQ and CRF-REQ 06-JAN-09 POBJCOD - CDF-REQ and CRF-REQ P21CDF.CDF04 P21CRF.CRF04 POBJDIR - CDF-REQ and CRF-REQ POBJCOD - CDF-REQ and CRF-REQ P31CDF.CDF01 P31CRF.CRF01 Reference: Case 482334 Symptom: CDF and CRF requesters require the response time counter minimum and maximum threshold values to be specified in whole numbers. Problem: The CDF and CRF minimum threshold value and maximum threshold value were defined as whole numbers. Response time counter, counter type 2, thresholds need the capability to be specified in terms of less than zero. Change: Created new versions of the CDF and CRF requesters. Implementation: Scup the new requesters into the POBJ files on the APMSOBJ subvolume. Complete a FUP PURGEDATA on the CDF, CDF0, and CRF data files. Complete a PERFGEN. Dependencies: None. SCR #3500 SKELB - rel3^ver1^sutl12^20090720 20-JUL-09 - rel3^ver0^sutl31^20090720 Reference: RPE Symptom: N/A. Problem: Updates to the valid BIN ranges allowed for Discover cards. Fourteen digit PANS within the following primary account number ranges will be deemed Discover card prefixes: "36000000" - "36999999" Sixteen digit PANS within the following primary account number ranges will be deemed Discover card prefixes: "30000000" - "30599999" or "30950000" - "30959999" or "38000000" - "38999999" or "39000000" - "39999999" or "60110000" - "60119999" or "62212600" - "62292599" or "62400000" - "62699999" or "628200000" - "6288999" or "64400000" - "64499999" or "650000" - "659999" Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3502 PREGEN - rel3^ver1^pre01^20090803 03-AUG-09 - rel3^ver0^pre06^20090803 SKELB - rel3^ver1^sutl13^20090803 - rel3^ver0^sutl32^20090803 GLOBAL - N31GLBL.GLBL14TG - N30GLBL.GLBL40TG Reference: Case 505383 Symptom: - Counter for prefix records with the same length is declared as an INT - Maximum number of records sharing the same prefix length is 65535 - IPF contains more than 65535 records with same prefix length. - Transactions incorrectly routed Problem: Counter of SPROUTE prefix records is an INT. Change: Increased the size of the SPROUTE prefix record counter to an INT(32). Implementation: Install the new PREGEN object on the XPNET subvol and accelerate the code using the PREAXCL file. Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Run the SKELMLBC step if required. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: All components of SCR 3502 must be installed at the same time. The authorization application process will abend during routing table builds if all components are not installed. SCR #3492 BASE - rel3^ver0^gate32^090608 25-JUN-09 - rel3^ver0^rel74^090625 BASE - REL3^VER1^GATE12^20090625 - REL3^VER1^BASE^REL23^20090625 Reference: Case 497435 Symptom: Service availability was not being updated between XPNET nodes which caused queuing when service providers were available to process messages. Problem: The local service providers are only on one XPNET node and have SMT set to -1. Node attribute USQMT is greater than zero. All of service providers stopped and started within the STD timer. No messages were routed and failed from the remote XPNET node before the STD timer expires. If all of the above is true and the queue count in the local USQueue is greater than USQMT when the STD timer expires, the XPNET node with the local service providers sends an internal message to all of the XPNET nodes it is connected to via a started LINK process to deactivate the remote LINK's as an external service provider on the other XPNET nodes. Once this occurs, any messages routed to this service on the remote nodes will queue in the USQueue in the remote node. The problem occurs because the local node does not notify the remote nodes the service is available again when the queue count in the USQueue drops below the USQMT value. This causes messages to continue to queue on the remote nodes even though the service providers are available and could be processing messages. Change: Changed the logic to not notify the remote XPNET nodes the service is not available when the STD timer expires and the queue count in the USQueue is greater than a non zero USQMT. This prevents the remote XPNET nodes from deactivating the LINK as an external service provider, so they do not need to be notified when the service is available again. This problem only occurs if no messages were routed from the remote XPNET node. If no messages are being routed, the remote node does not need know the service is not available. If a message is routed from the remote node and the USQueue count is greater than a non USQMT, it will be failed. This will also cause the remote link to be deactivated. However, this is handled properly, the local XPNET Node keeps track of the fact that a message has been failed and the remote node must be notified when the service becomes available. So if a message failure occurs, the remote node will be notified the service is available when the USQueue count drops below the USQMT value. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: None. SCR #3493 BASE - rel3^ver0^elog07^090626 26-JUN-09 - rel3^ver0^rel74^090625 BASE - REL3^VER1^ELOG04^20090626 - REL3^VER1^BASE^REL23^20090625 Reference: Case #461592, #490586 Symptom: Trap 3 (stack overflow) in proc ELOG^CREATE^EVENT due to a message failure 119 in proc ENQUEUE when the internal EMS queue had reached its data structure limit. Problem: SCR 2867 was added to prevent trap 6704 when the count in the queue control block reached its max: XPNET 3.0 (65,535), XPNET 3.1 (2,147,483,640). Instead of dumping when this condition occurs, SCR 2867 caused XPNET to fail the next msg(s) with a 119 ( NOM ) failure code until the queue count drops below the max. This works for process and station queues where the messages queued have a valid symbolic source and dest in the message header. EMS event messages are not routed symbolically and when they are failed they cause an unknown dest to be added which causes an EMS event to be created. Since the EMS queue is still at its max, the new EMS message is failed. This recursion continues until the stack overflows. Change: Changed procedure ELOG^CREATE^EVENT to set message disposition to 2 when the message header for EMS events is created. This will cause an EMS message to be quietly dropped when it is failed instead of trying to route it. There is no valid reason to symbolically route or fail an EMS event. Again this to prevent the XPNET Node from dumping when a data structure limit has been reached. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: None. SCR #3494 BASE - REL3^VER1^GATE12^20090625 26-JUN-09 - REL3^VER1^BASE^REL23^20090625 Reference: Case #484983 Symptom: XPNET abends with a trap SIGNUM 11 in various procs (i.e. DEST^SERVICE^ROUTE and DEST^DELETE^SERVICE) because a single bit in memory was corrupted. The trap and procedure could vary depending on the action in progress and the location of the memory corruption. EMS events 3000, 3001, 3002 or 3003 may be generated with ivalid information. 09-04-23;14:53:29.189 \SYS.$P1AN ACI.XPNET.3100 3000 ????????O??????? exceeded queue alert threshold of 538989381, current queue 1044266558, maximum queue 1044266558, total free bytes 130279496 Problem: If a DEST was deleted while it had a QAT or NOM timer in progress, memory could be corrupted when the timer expires. When a dest enters the QAT or NOM state, a timer based on QED is added using the address of the dest structure in memory. When the timer expires, it uses this address to access the dest structure to determine if the object queue is still above the QAT or NOM settings. If the current queue count exceeds the QAT when the timer expires, event (3000) is generated, a single bit (qcb.qat.qed^in^progress) is set to true "1" and a new timer is added. If the queue count is below the QAT, event (3001) is generated, the timer is not re-added and (qat.qed^in^progress) is set to false "0". The problem occurs if the destination was deleted in between the QED interval while a QAT or NOM timer was still in progress. The memory for the dest structure is returned and when the timer expires, the data in the dest structure could be invalid if it has been re-allocated. The logic examining the current queue count and QAT/NOM settings is looking at garbage. This is why events 3000-3003 may be generated with invalid information. The logic will set qcb.qat.qed^in^progress based on the values in memory. This may or may not cause a problem depending on if the memory has been re-allocated, if the bit was flipped or not and if the location of the bit was in a sensitive area (i.e. an address) in the new block. Under XPNET 3.1, the QAT/NOM logic for destinations changed significantly due to addition of the DEST OBJECT. The problem is that this new logic did not account for the fact that the dest may not exist or was deleted and re-added when the timer expires. This logic was part of previous releases of XPNET, but was not properly changed to work with the new DEST data structures in XPNET 3.1. Change: Added logic to cancel the QAT and NOM timers if they are active when the dest is deleted. This is the same way QAT and NOM timers are handled when processes and stations are deleted. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: XPNET 3.1 only. SCR #3495 BASE - REL3^VER1^ONCF^SYS15^20090625 29-JUN-09 - REL3^VER1^BASE^REL23^20090625 - rel3^ver0^rel74^090625 - rel3^ver0^oncf^sys26^090625 Reference: Case #490775 Symptom: ADD of object replacing UNKNOWN dest results in a warning. For example: ADD STATION \PROD.P1A^NODE.S1A^HISO01 Station S6A^HISO01 add warning, dup obj has been found. Station \PROD.P1A^NODE.S1A^HISO01 added. Problem: When an ADD command is done, SERVER-NCP does a preliminary ADD-OK command to determine if an object with this symbolic name is already configured. If there is one, a warning is returned to indicate a duplicate object is configured. This is to avoid possible routing errors if duplicate enabled objects are inadvertently configured. This does not prevent the ADD unless the object found was on the same XPNET node the object is being added to. If an unknown dest with this symbolic name has been added to the routing table, it causes the ADD^OK logic to think there is a duplicate. The warning does not cause any problems, it just causes confusion. The object is correctly added and the routing tables are properly updated. Change: Changed the ADD^OK logic to check the dest type when the symbolic name is found in the routing table. If it is an unknown dest, the warning is not returned. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: None. SCR #3496 BASE - rel3^ver0^rel74^090625 01-JUL-09 - rel3^ver0^exec32^090625 BASE - REL3^VER1^EXEC13^20090625 - REL3^VER1^BASE^REL23^20090625 Reference: Case #488851 Symptom: The ADD of a disabled copy of an ATM to a remote XPNET node to facilitate disaster recovery and high availability failed. The ADD returned an error 57 (NCP^ERR^DUP^DEST) which  indicates the XPNET node believes the station already exists even though an INFO STATION does not show this ATM (enabled or disabled). Problem: This station exists on another XPNET node and an external destination with this symbolic name is in the routing table of the XPNET node the object is being added to. This causes the XPNET node to return error NCP^ERR^DUP^DEST even if the object is being added disabled. Change: Added logic to allow the ADD of a disabled object even if there is an entry with this symbolic name in the routing table. A disabled object does not affect the routing table, so there is no reason to prevent the ADD. This dest must be removed from the routing table before the object can be enabled. The ADD will work, but the ENABLE will fail if the entry is still in the routing table. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: None. SCR #3501 CTS - REL3^VER1^CTS09^20090815 15-AUG-09 - rel3^ver0^cts30^090815 Reference: case #497048 Symptom: - Node Dump with Trap Dump 6559 when INPUT OFF/ON Command set on Line Problem: If a connection exists and the station is then stopped the code does not initialize conn^cb.conn^id. If a Disable Input is done on the line cts^send^disable^input^sig^rcv is called which transitions the code into the closed state and signals the RECV FSM to stop. When the Enable Input is done on the line cts^send^enable^input^sig^rcv is called. In this proc a check is done on the conn^cb.conn^id. If this is set to a valid connection id the code will incorrectly signal a start. This causes the code to post a RECV when the filenum is set to -1 which causes the dump 6559. The filenum was correctly set to -1 when the stations was stopped. Change: Set the conn^cb.conn^id to -1 once the dealloc completes and the evaluate stopped status is done. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3498 3.0 POBJ - T3270-NCSS 23040 (D30) 19 AUG 2009 11:09:33 10-JUL-09 T6520-NCSS 23040 (D30) 19 AUG 2009 11:09:58 3.1 POBJ - T3270-NCSS 25088 (D30) 19 AUG 2009 11:15:38 T6520-NCSS 25088 (D30) 19 AUG 2009 11:16:05 Reference: Case 500607 Symptom: When using the SEC screen ADD LIKE or DELETE function the screen locks up and the NCSS server starts to utilize a large portion of the CPU. Excessive number of process create error event messages for SERVER-NCSS. Problem: There was a configuration error in the NCSS server definition in the PATHCONF which prevented it from starting. PATHMON replied to the requester with an error, however, the requester failed to handle the error and retried the request indefinitely without notifying the operator of the problem. Change: Modified the NCSS requester to increment a loop counter when performing the special ADD LIKE or DELETE logic originated from the SEC screen. This will only allow the loop to be performed 1000 times at which time it will exit. This will fix this problem and any unforeseen future issues. Implementation: Install the new XPNET POBJ. Dependencies: None. SCR #3517 BASE - REL3^VER1^BASE^REL24^20091203 14-JAN-10 - REL3^VER1^NSTP07^20091203 GLOBAL - N31GLBL.GLBL15TG BASE - rel3^ver0^rel75^091203 - rel3^ver0^nstp20^091203 GLOBAL - n30glbl.glbl41tg NETETCL - N31EMS.EMS10EA NETEC - N31EMS.EMS10EC NETEDDL - N31EMS.EMS10ES NETETAL - N31EMS.EMS10ET NETECOB - N31EMS.EMS10EX NETTPLO - N31EMS.EMS11PO NETTPLS - N31EMS.EMS11PS NETETCL - n30ems.ems28ea NETEC - n30ems.ems28ec NETEDDL - n30ems.ems28es NETETAL - n30ems.ems28et NETECOB - n30ems.ems28ex NETTPLO - n30ems.ems34po NETTPLS - n30ems.ems34ps Reference: Case #01006426 Symptom: XPNET dumps with #6585. Problem: This logic has been modified twice, once for error 14 (fenosuchdev) - SCR 2683 and once for error 201 (fepathdown) - SCR 3124. This time an error 30 occurred which again caused the XPNET node to dump. Before this change if an error occurred on a nowait completion to a CHECKOPEN, the code called FILE_GETINFO_ to get the filename and the device type of the file number being checkopened. If this returned an error (other than 14 or 201) XPNET would dump. In the dump, the OPEN completed without an error, but the checkopen failed. Normally the OPEN would fail, so the CHECKOPEN would not be done avoiding the dump. In this case an OPEN in progress completed OK, but before the CHECKOPEN could complete NSK returned the error 30. These operations are normally completed in milliseconds. Change: Now if the call to FILE_GETINFO_ fails (for any error), XPNET will generate a new event (6425) and continue (as it would have if the call to FILE_GETINFO_ had not failed). 6425 - "File <1>, FILE_GETINFO_ error <2> (<3>)" The worst case if the FILE_GETINFO_ fails would be the information in event message #6223 may be invalid. The call to FILE_GETINFO_ was being performed to return the name of the file open that failed for event #6223. In this saveabend, even though the call to FILE_GETINFO_ failed (probably due to the type-info parameter), the name and name length were properly returned, so this may not be an issue. Even if this does fail, it is not a valid reason to terminate the XPNET node. If the logic continues, it will close the file number in the primary XPNET and dispatch a nowait open error with the error that occurred on the checkopen - in this case an error 30. This will keep the XPNET primary and backup in sync (file number not open in primary or backup), so the backup will be able to process correctly if a takeover occurs. The calling logic has to be able to handle the open error (or it would not have issued a nowait open). The action will be based on STARTUP logic for processes or error action/reinstate logic for lines/stations. Also removed the type-info parameter to return the device info in the call to FILE_GETINFO_. It was not being used and was unnecessary. This may also reduce the number of errors returned. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Dependencies: None. SCR #3521 CTS - REL3^VER1^CTS11^20100530 30-MAY-10 - REL3^VER0^CTS32^100315 IPOS - REL3^VER0^IPOS10^100530 - REL3^VER1^IPOS08^20100530 INON - REL3^VER0^INON01^100530 - REL3^VER1^INON03^20100530 Reference: Case #1072230 Symptom: XPNET Dumps with a #8335 Problem: If IPOS sends a message to the terminal it transitions to the WAIT-FOR-ACK state. While waiting for the ACK from the terminal the message that was sent could go stale.(msg^timelimit exceeded) If this occurs the msg is failed back to the sending process by the CTS layer. The IPOS layer is never notified of the msg failure. Once the message is failed the address of the message is no longer a valid address. Because the IPOS layer has not been notified of the failure it tries to access the message with the invalid address causing XPNET to dump with a #8335. Change: Added code to CTS to call CTS^END^TO^END in order to signal IPOS that a message failure occurred. IPOS will now perform a disconnect when this event occurs. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3522 IPOS - REL3^VER0^IPOS10^10053 30-MAY-10 - REL3^VER1^IPOS08^20100530 Reference: Case #1066428 Symptom: XPNET Dumps with a #8306 Problem: IPOS state machine is not coded to handle a timeout occurring when in the PASSTHRU STATE. Timers are set when an ENQ or a EOT are sent. The EOT timer was set and the TCPSRV process did not reply to the send of the EOT before the timer expired. This caused a timeout event to occur when in the PASSTHRU STATE. Because the state machine was not coded to handle this event the code dumps with a #8306. Change: Added code in the state machine to handle a timeout event. In this case the code will signal a dealloc of the connection. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3523 NETCJRD - rel3^ver1^cjrp07^100510 05-MAY-10 NETCJRD - rel3^ver0^cjrp14^100510 Reference: Case #01065084 Symptom: In some cases NETCJRD does not display ALTER DEVICE DESTSTRING and PROTOCOLSTRING commands properly. ONCF Command: ALTER DEVICE D1A^TCP,ADD DESTSTRING 1,P1A^AUTH,297,"77" Displayed as follows: 7477/44/09 47:68:69.973 VICE \NSC01.P1A^ ALTER DEVICE D1A^TCP,ADD DESTSTRING 1,P1A^AUTH, 297, "45" ALTER DE Problem: Internal buffer was not large enough. This caused a problem if the DEVICE contained too many DESTSTRING or PROTOCOLSTRING entries. Change: Increased buffer from 400 bytes to 4000 bytes in order to handle up to 32 DESTSTRING and PROTOCOLSTRING entries per DEVICE. Implementation: Install the new NETCJRD program and rerun with the same Command Journal File. Dependencies: None. SCR #3526 BASE - REL3^VER1^ONCF^SYS16^20100622 22-JUN-10 - REL3^VER1^MMGR05^20100622 - REL3^VER1^BASE^REL25^20100622 BASE - rel3^ver0^oncf^sys27^100622 - rel3^ver0^exec33^100622 - rel3^ver0^rel76^100622 GLOBAL - n30glbl.glbl42tg Reference: Case 440706 (SalesForce 993106). Symptom: - XPNET abends with signal 26 (loop timer) or trap 6410 (memory exhausted). - Occurs sometime after "control node,RESIZESEGMENT" command is issued. - Procedure PROCESS^OUTPUT^TASK should be towards top of Inspect stack trace. The stack trace may vary somewhat above this procedure. - Occurs when error 22 is returned to a WTITEREADX call. - Events similar to the following may be emitted over and over if the XPNET log was not queuing: 07-08-22;10:50:30.434 \SYS.$P1AN ACI.XPNET.3100 6200 A Guardian writeread error 22 (application parameter or buffer address out of bounds) to Process P1A^PROCESS occurred Problem: An error 22 is received when a WRITEREADX is performed to a Satellite process sometime after a "control node,RESIZESEGMENT" command was executed. The error is logged and the WRITEREADX is retried immediately resulting in another error 22. This causes a looping condition which either fills memory with log events causing trap #6410 or causes our loop timer to expire causing trap #26. The memory manager allocates memory starting at the end of the memory segment and works towards the front. When XPNET is first started, a number of memory tables and the NEF are allocated, so they land at the end of the segment. When processes are started later, an I/O buffer is allocated, but those come from the "middle" of the memory segment since the end of the segment is full by then. When we have a message to send to a process, we issue a WRITEREADX from the above I/O buffer. For a reason yet to be determined, we miscalculate the READ size and issue the "read part" beyond the end of the buffer. When the buffer is in the "middle" of the segment as normal, this does not cause error 22. Since the application doesn't send more to XPNET than what they called NETINIT for (and since the buffer is at least that large), it doesn't normally cause a problem. The problem happens after doing RESIZESEGMENT because the new memory is added at the end of our memory segment, behind existing tables and the NEF. When a process is started then, and the I/O buffer is allocated, the memory manager starts at the end and finds space for it. When a WRITEREADX is issued for an incorrect read length at this point, Guardian determines the read could go beyond the end of the segment and returns error 22. Once XPNET traps and is restarted, memory is again filled from the back with tables and the NEF, so the error 22 doesn't happen. The workaround is to stop and start XPNET after altering EXTPAGES rather than doing "control node,RESIZESEGMENT". Change: After a RESIZESEGMENT is done, some internal tables are de-allocated and re-allocated so they use memory at the end of our extended memory segment. To be sure enough memory will be available for these tables, EXTPAGES must be increased by at least 118 pages for XPNET 3.1 (27 pages for XPNET 3.0) before doing a RESIZESEGMENT command, otherwise that command will be rejected. This SCR resolves ACI Hotline "Issue #02, 04-Feb-2010". Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3539 SKELB - rel3^ver1^sutl15^20101115 15-NOV-10 - rel3^ver0^sutl34^20101115 BAUTILS - $DATA01.L10UTIL.BAUT02TS Reference: Case 1098271 Symptom: BASE24 satellites running with SKEL bound in rather than as a library can abend. Problem: BASE24 satellites and SKEL have procedures called lconf^init and lconf^read that perform similar but not identical functions. This is not an issue when SKEL is run as a library but can cause a satellite to abend when satellite and skel code are bound together. Change: We are renaming these procedures in SKEL to skel^lconf^init skel^lconf^read Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. This causes no compatibility issues with any version of SKEL or satellite code when SKEL is run as a satellite. When SKEL is bound in with a satellite both modules will call the correct "..lconf.." procedure. SCR #3540 SKELB - rel3^ver1^sutl15^20101115 15-NOV-10 - rel3^ver0^sutl34^20101115 Reference: Case 1099854 Symptom: Text token data in some PCI log messages is preceded by four blank characters. This makes it appear that the token is being truncated by four characters. Problem: SCR #3519 modified SKELB to include tens, hundredths, and thousands of a second for the GEN TIME LCT EMS token. This required insertion of a four byte time field into the internal message header. The PCI code was not updated to use the new header information so the text token was being displayed incorrectly. Change: Modified log^messagex to account for the new message header. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3542 SKELB - rel3^ver1^sutl15^20101115 15-NOV-10 - rel3^ver0^sutl34^20101115 Reference: Internal Symptom: None Problem: Customers had to manually bind in the skel migration library. We are finding that almost all customers run with this and that it is now an inconvenience for them. Change: We are now building it into the release version of skel. A new SKEL bind file, SKELMLBU, will build "SKELOPIN" (Skel-LoPin), a low-pin-only version of SKEL for customers who do want to run lowpin. This bind file removes the ACI subsitution procedures AWAITIO, GETCRTPID and MYPID. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3547 MQSIO - REL3_VER1_MQSI08_20110201 01-FEB-11 REL3_VER1_CTSE03_090330 CTSEPLO - ctse05po CTSEPLS - ctse05ps Reference: Case #1114015 (previous case #401567, SCR3362) Symptom: - The following is logged for an MQSeries process: ERROR: EMSTEXT FAILED ON ATTEMPT TO PRODUCE TEXT FOR EVENT UPPER WORD OF ERROR VALUE IS 12 LOWER WORD OF ERROR VALUE IS 14 05-10-04;11:35:02.790 \SYS.$MQSI ACI.XPCTSE.3000 1008 Backup process ? created. Problem: CTSE logs the above message with the xpctse-tkn-phandle token. This token instructs EMS to resolve the PHANDLE to a printable form to log. If the process is no longer running when EMS attempts to resolve the PHANDLE an error occurs and the above error is logged. This problem was fixed previously in CTSE using SCR3362. The CTSE fix was bound into TCPCLI and TCPSRV, but it was not bound into MQSIO at that time, so the problem continues to occur for MQSI. The fix for SCR3362 included a change to the CTSE EMS template file (CTSETPL*). Token xpctse-tkn-phandle was replaced with token xpctse-tkn-char-var for the process name. This caused a dependency between the CTSETPL* files and all CTSE's. Some CTSE's would then log "process ?" even when the process was running. Change: Changed the code to resolve the phandle to a string and log the message using the xpctse-tkn-char-var token. EMS will now store the PPD name of the process and can log message 1008 when the process no longer exists without the error. Bound the version of CTSE with SCR3362 into this version of MQSI. No code changes were made to MQSI itself. SCR3547 includes a change to the CTSETPL* files allowing token xpctse-tkn-phandle or xpctse-tkn-char-var to be present. Implementation: Install the CTSETPL* and MQSIO files. On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.1 Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. The MQSIO object must be bound with IBM's MQSeries library. Obey the MQSIBC file to bind the ACI MQSIO interim object with IBM's MQSeries library. Stop all CTS/MQSI stations. Stop the MQSI process(s). Restart the MQSI process. Restart CTS/MQSI station. Dependencies: None. SCR #3549 BASE - REL3^VER1^BASE^REL26^20110223 23-FEB-11 - REL3^VER1^PROC14^20110223 Reference: Case 1114266 Symptom: - A process that uses the XNCONF will not start. - The following XPNET event is logged: 11-02-23;11:56:50.102 \SYS.$P1AN ACI.XPNET.3100 2119 Process P1A^PRO creation failed, process create error 24 (Define error) error detail 2 - Altering various unrelated attributes on XPNET objects allows the process to start. Problem: Variable "def^len^total" is not initialized if the process has "DEFINES ON", but no defines are specified in the XNCONF. Workaround: Alter the process to set "DEFINES OFF". Change: Initialized variable "def^len^total" in all cases. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.1 only. SCR #3553 BASE - REL3^VER1^ELOG05^20110307 07-MAR-11 - REL3^VER1^BASE^REL27^20110307 Reference: Case #01119513 Symptom: - Station diagnostic events are not properly suppressed when STADIAG is OFF (node or station level). Problem: When logic was added to XPNET 3.1 to allow event suppression at the object level, instead of evaluating the station flag the line diagnostic flag was checked. Change: Changed the logic to properly examine the station diagnostic suppression flag instead of the line. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.1 only. SCR #3556 XNLIB.XNLIB - rel3_ver1_http12_110430 30-APR-11 rel3_ver1_http_util08_110430 rel3_ver1_xnlib_rel26_110430 XNLIB.XNLIBEN - rel3_ver1_http12_110430 rel3_ver1_http_util08_110430 rel3_ver1_xnlib_rel26_110430 XNLIB.XNLIBER - rel3_ver1_http12_110430 (relinkable) rel3_ver1_http_util08_110430 rel3_ver1_xnlib_rel26_110430 XNLIB.XNLIBN - rel3_ver1_http12_110430 rel3_ver1_http_util08_110430 rel3_ver1_xnlib_rel26_110430 XNLIB.XNLIBR - rel3_ver1_http12_110430 (relinkable) rel3_ver1_http_util08_110430 rel3_ver1_xnlib_rel26_110430 HTTPLIB - rel3_ver1_http_rel12_110430 rel3_ver1_http_util08_110430 Reference: 1126953 Symptom: - A XPNET Web Application request with a HTTP cookie buffer ending with a cookie name but no value (name=) is rejected. - a log event similar to the following is emitted: 11-04-30;21:22:13.456 \SYS.$P1AT ACI.XPSATE.3000 5 Servlet Engine received an invalid request. HTTP function HTTP_WGI_TO_AJPV13, status=2 (invalid message), status-detail-1=18 (invalid Cookie data), status-detail-2=3100. first 192 bytes: ......0:0000 FFFF FFFF FFFF FFFF FFFF:........... .....16:FF20 5031 495E 544F 4D43 4154:. P1I^TOMCAT .....32:3630 3120 2020 FFFF 0000 0000:601 .. .....48:FFFF FFFF FFFF FFFF FFFF FFFF:............ .....64:FFFF FFFF FFFF FFFF FFFF FFFF:............ .....80:FFFF FFFF FFFF FFFF FFFF FFFF:............ .....96:FFFF FFFF FFFF FFFF FFFF FFFF:............ ....112:FFFF FFFF FFFF FFFF FFFF FFFF:............ ....128:FFFF FFFF FFFF FFFF FFFF FFFF:............ ....144:FFFF FFFF FFFF FFFF FFFF FFFF:............ ....160:FFFF FFFF FFFF FFFF FFFF FFFF:............ ....176:FFFF FFFF FFFF FFFF FFFF FFFF:............ (the above display was abbreviated to fit this format) Problem: XNLIB (HTTPLIB) routine HTTPUTL_CKIE_GET_ONE_CKIE did not allow the last cookie in a HTTP cookie buffer to be without a value (did not allow it to end "NAME="). This code has been in place since late 2002 (scr3075), and this is the only known occurrence of the problem. Change: Changed parsing in HTTPUTL_CKIN_GET_ONE_CKIE to allow the last cookie in a HTTP cookie buffer to not have a value. Implementation: Since XNLIB and APPLIB can be run as user libraries, do the following only after taking appropriate action to avoid library conflicts. Install the new XPNET files on the XPNET subvolume. Install the new XNLIB files on the XNLIB subvolume. If APPLIB is used, it should be rebuilt using the APPLIBBC and APPLIBB files to include the modified MHDRLIB library. Follow the directions in APPLIBB for completing this process. The resulting APPLIB object can be renamed to SKELB if desired. If on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. APPLIB may also be accelerated separately by obeying the APPLAXCL file. The non-native XNLIB library object can be accelerated using the XNLIB.XNAXCL obey file. If using an Itanium NonStop machine (NS-Series), accelerate appropriate files using the following OCA macros: - XPNET.OCAAPPL (for XPNET.APPLIB, if rebuilt) - XPNET.OCANLIB (for XPNET.NETLIB) - XNLIB.OCAXNLIB (for XNLIB.XNLIB) Application processes which use APPLIB or XNLIB as a run-time library must be stopped and restarted in order for the new library to take effect. In particular for this case, all Satengine processes must be stopped and restarted. Application processes which bind one of the above libraries must be re-compiled or re-bound with the new library. SCR #3557 ---OSS WAX 1.1 MIPS version (installed on XPNET subvol) 30-APR-11 Tomcat 6.0.20 requires a minimum of NSJ5. NSJ5 is not supported on MIPS, so there is no MIPS version. ---OSS WAX 1.1 ITANIUM version (installed on XPNET subvol) PXSY6020 - EOF 282112 14MAR2010 21:03 sysaci/sysweb/satengine T0000D45_30APR11_WAX11_SATE13 sysaci/sysweb/satengine/AciIntraprocess.jar sysaci/sysweb/satengine/tomcat/RunAppl.jar sysaci/sysweb/satengine/tomcat/ajp13.jar PXSY602L - EOF 495 14MAR2010 21:03 listing of above files Reference: 1126953 Symptom: - Satengine abends with a stack looking something like below. will display differently depending on what system the "bt" command is executed on, if procedures are properly displayed "memcpy" or "memmove" should be present. Frame #10 should look much like the below. (eInspect 1,1133):bt #0 0xfffffffff90521a0 in () #1 0xfffffffff124f8e0 in () #2 0xfffffffff1250a40 in () #3 0xfffffffff22bfd60 in () #4 0x7ea47d20 in () #5 0x7f7d70e0 in () #6 0x7ea53f70 in () #7 0x7ea41750 in () #8 0xfffffffff030b830 in () #9 0xfffffffff236f1c0 in () #10 0x7000c790:0 in util_log_get_msg_as_hex_for_display (txt=0x8032210 "", msgcount=, spec_offset=, offset=, tkn_addr=) at /user/nsdev/w11sate/sate.c:3579 #11 0x700070f0:0 in process_xpnet_data_msg (in_msg_ptr=0x8032210 "", in_msg_txtptr=0x803228a "", in_msg_txtlen=3456, cnt_rd=3578, originator_ptr=0x6fffff2c "S1A^PROCESS ", src_type=2, reply_lgth=18000) at /user/nsdev/w11sate/sate.c:2174 #12 0x70016840:0 in main (argc=, argv=, envp=) at /user/nsdev/w11sate/sate.c:5274 #13 0x70017100:0 in _MAIN () at \SPEEDY.$RLSE.T8432H02.CPLMAINC:46 (eInspect 1,1133) Problem: When building text for log message #5, a length can be miscalculated in rare situations yielding a negative value. This causes a "memcpy" to be done for a large length which corrupts memory. This code has been in place since early 2003 (scr3080), and this is the only known occurrence of the problem. Change: Corrected the length calculation. Implementation: Install the new XPNET files on the XPNET subvolume. Perform the following steps to complete the installation of the new Satengine object: 1) Restore the PX* files mentioned above to a subvolume on a non-virtual disk volume. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3) If installing on NS-Series (Itanium), follow the instructions below. Stop any running Satengine processes. Copy the 'satengine' file from the temporary directory to the installation directory. Example (save the old satengine file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/satengine \ /user/sysaci/sysweb/zzold Example (install the new satengine file): > cp -p /user/temp/sysaci/sysweb/satengine \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Restart Satengine processes. Dependencies: None. SCR #3532 BASE - rel3^ver0^oncf^lnk07^110516 05-MAY-11 - rel3^ver0^rel77^110516 BASE - REL3^VER1^ONCF^LNK05^20110516 - REL3^VER1^BASE^REL28^20110516 Reference: Case #01088482 Symptom: - Valid LINK process marked as invalid - ONCF commands [i.e. START, STATUS, STATISTICS] fail with "object is invalid" response. Problem: When the XPNET node is started, if a LINK process PPD is pointing to a resource node on another Tandem system, it is converted from external format to internal format. [ i.e. \SYS2.$P1AN to \# P1AN ] NSK procedure nodename_to_nodenumber_ is called to perform this. This normally returns the remote Tandem nodes system number. However, if EXPAND access to this system is not available, nodename_to_nodenumber_ will return an error 18 and 255 for the system number. When this occurs, it causes this LINK process to be marked as invalid because the system number is not valid. The only way to fix this was to delete and re-add the LINK process or stop and start the XPNET node after EXPAND access to the remote system was re-established. Change: Added logic when a START LINK process command is executed. If the LINK is invalid and ppd is remote call logic to validate the LINK process again. If this succeeds [i.e. remote system is now accessible] then mark the LINK as valid, update the system number in the LINK PPD and execute the START LINK command. If it is still invalid, the START command will fail with "object is invalid" as it would prior to this change. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3533 BASE - REL3^VER1^BASE^REL28^20110516 16-MAY-11 - REL3^VER1^ONCF^CJ05^20110516 - REL3^VER1^ONCF^DEST06^20110516 - REL3^VER1^ONCF^LNK05^20110516 - REL3^VER1^ONCF^PRO11^20110516 - REL3^VER1^ONCF^STA08^20110516 - REL3^VER1^ONCF^SYS17^20110516 - REL3^VER1^QUE06^20110516 GLOBAL - N31GLBL.GLBL16TG DDLC - S31SDDL.SDDL07DC DDLCOB - S31SDDL.SDDL07DX DDLFUP - S31SDDL.SDDL07DZ DDLS - S31SDDL.SDDL07DS DDLTAL - S31SDDL.SDDL07DT NCPDC - S31NCPI.NCPI10DC NCPDCOB - S31NCPI.NCPI10DX NCPDCB74 - S31NCPI.NCPI10DV NCPDDDL - S31NCPI.NCPI10DS NCPDFUP - S31NCPI.NCPI10DZ NCPDTAL - S31NCPI.NCPI10DT NCPDTCL - S31NCPI.NCPI10DA NETDDLS - N31GLBL.GDDL05DS NETDC - N31GLBL.GDDL05DC NETDTAL - N31GLBL.GDDL05DT NETDFUP - N31GLBL.GDDL05DZ NETETCL - N31EMS.EMS11EA NETEC - N31EMS.EMS11EC NETEDDL - N31EMS.EMS11ES NETETAL - N31EMS.EMS11ET NETECOB - N31EMS.EMS11EX NETTPLO - N31EMS.EMS12PO NETTPLS - N31EMS.EMS12PS NCPCOM - REL3^VER1^NCPC20^20110516 - REL3^VER1^NCPL19^20110516 - REL3^VER1^RLBK04^20110516 - S31NCPL.PREL10TG - S31NCPL.PARS13TG - S31NCPL.NCPL09TG - S31NCPL.NCPL10DS SVNCPI - REL3^VER1^REL18^20110516 - REL3^VER1^NCP16^20110516 - REL3^VER1^OBJ11^20110516 - S31NCPI.NCPRSP07 - S31NCPI.NETCMD05 - S31NCPI.NETRSP06 SVNCS - REL3^VER1^SNCS17^20100903 - REL3^VER1^NCPL19^20110516 SVNCSP - SVNCSP-31-09 - SVTAB-A-31-07 NCSPREPT - NCSP-REPORT-REL31-07 SVNCSP24 - SVNCSP-NET24-31-10 - SVTAB-A-31-07 NETCJRD - REL3^VER1^CJRP08^110516 Reference: Case #01008865 Symptom: - PCI requirement to set a specific file code on NOM and QWRITE files created. Problem: The was only possible by manually changing this via FUP after the data was written and the file was closed which did not meet PCI requirements. Change: Added XPNET NODE attributes NOMFILECODE, QWRFILECODE to set the file code when these files are created and modifier FILECODE to each CONTROL, QWRITE command to allow the file code to be set when the file is created. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Update NCSP if using ONCF security. ALTER NODE , NOMFILECODE ALTER NODE , QWRFILECODE Optionally specify a FILECODE modifier when issuing a CONTROL , QWRITE command. This will override the NEF setting for QWRFILECODE when the specified file is created. On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.1 Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Dependencies: XPNET 3.1 only. SCR #3534 BASE - REL3^VER1^AUD04^20110516 16-MAY-11 - REL3^VER1^BASE^REL28^20110516 BASE - rel3^ver0^rel77^110516 - rel3^ver0^aud07^110516 Reference: Case #01086748 Symptom: - XPNET dumps with a trap 2 in procedure audit^msg. Problem: This is similar to the problem fixed by SCR 2976. This trap will occur if the calculation to determine if the current disk file pointer + the size of the message being audited is greater than the file EOF and the result of this calculation is larger than an int(32) (2,147,483,647 bytes). As a work around reduce the value of NODE attributes ADEXTENTS and ADMAXEXTENTS. The combination of these multiplied together can not exceed (1,048,576) until this fix is installed. Change: Modified the logic to use fixed arithmetic. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3535 BASE - REL3^VER1^NSTP08^20110516 16-MAY-11 - REL3^VER1^BASE^REL28^20110516 GLOBAL - N31GLBL.GLBL16TG SVNCPI - REL3^VER1^REL18^20110516 - REL3^VER1^NCP16^20110516 - REL3^VER1^RN10^20110516 - REL3^VER1^OBJ11^20110516 - REL3^VER1^BKUP04^20110516 BASE - rel3^ver0^rel77^110516 - rel3^ver0^nstp21^110516 GLOBAL - n30glbl.glbl43tg SVNCPI - rel3^ver0^rel39^05162011 - rel3^ver0^ncp36^05162011 - rel3^ver0^rn20^110516 - rel3^ver1^obj24^110516 - rel3^ver0^bkup05^110516 Reference: Case #01090382 Symptom: - Unable to control/prevent system autostart after unplanned outage. Problem: Due to a power issue an entire Tandem system was lost and the customer switched to a disaster recovery system. When the original system was restored, they re-started Pathway. As part of this they started the NCPI servers, which in turn started ALL of the XPNET nodes. Because the XPNET STARTUP was set to AUTOMATIC, the nodes performed a WARMSTART. At this point they were not ready for the lines, stations and processes to restart [ DR system was still active and processing transactions ], however, they was no way to prevent or control this. During an orderly shutdown/switch to a disaster recovery system, the customer would normally alter the node startup to command to prevent this. However, during an unplanned outage, there was no way to do this. Change: Added new PARAM "PROHIBIT-AUTOSTART" to server NCPI. If this param is present and set to "ON", the XPNET node startup will behave the same as when the NODE STARTUP attribute is set to COMMAND. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) If performing PATHCOLD, edit PATHCONF and add following under each NCPI server class. SET SERVER PARAM PROHIBIT-AUTOSTART ON If performing PATHCOOL, make sure not to start the NCPI servers [ remove or comment out START SERVER NCPI commands in the PATHCOOL/PATHSTRT obey file ]. From PATHCOM: [ repeat for each NCPI server class ] ALTER SERVER SERVER-NCPI-nn, PARAM PROHIBIT-AUTOSTART ON Then START SERVER SERVER-NCPI-nn Remember to reset PATHCOOL/PATHSTRT file so NCPI servers are started next time a PATHCOOL is performed. After system is restarted remove the new PARAM or else the NODE AUTOSTART logic will be disabled if the node does abnormally terminate after the system is restored. If a PATHCOLD was performed comment out or remove SET PARAM statement in the PATHCONF. If a PATHCOOL was performed, stop the NCPI process: From TACL: STOP <$NCPI PPD> or From NCPCOM: DELIVER NODE , "ABORT-NCPI" From PATHCOM: [ before the NCPI process restarts ] ALTER SERVER SERVER-NCPI-nn, RESET PARAM PROHIBIT-AUTOSTART or ALTER SERVER SERVER-NCPI-nn, PARAM PROHIBIT-AUTOSTART OFF Dependencies: None. SCR #3536 BASE - REL3^VER1^EXEC14^20110516 16-MAY-11 - REL3^VER1^BASE^REL28^20110516 BASE - rel3^ver0^rel77^110516 - rel3^ver0^exec34^110516 Reference: Case #01089813 Symptom: - Customer was able to add an enabled object under a disabled XPNET node. - Object can be enabled under a disabled XPNET node. Problem: An XPNET NODE can not be disabled if any objects under that node are enabled, however, once the node was disabled there was no logic to prevent an enabled object from being added or a disabled object from being enabled. Change: Added logic to prevent this if the XPNET node is disabled. The ADD and ENABLE commands will now fail as follows if the node is disabled. NODE 9 > enable process \sys1.p1a^node.p1a^auth1 Process P1A^AUTH1 enable failed, cmd is inv for related node state disabled. NODE 10> add process \sys1.p1a^node.p1a^auth2 Process P1A^AUTH2 add failed, cmd is inv for related node state disabled. The object can be still be added as disabled and enabled after the XPNET node is enabled. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3548 SKELB - rel3^ver1^sutl16^20110315 15-MAR-11 - rel3^ver0^sutl35^20110315 Reference: Case #1115799 Symptom: - Satellite abends. The stack appears good but global zero has been overwritten. - Global zero can be evaluated using the following Inspect commands inspect add program zzsa1234 ( where "zzsa1234: is the name of the saveabend file) -$Z342-low _$Z342_a 0s,2 000153: .SK. .EL. _$Z342_ If the values ".SK. .EL." do not appear then global zero has probably been overwritten Problem: A call to logmessage (or log^message or log^message^) is passed a zero (for PCI code) or or negative number (PCI and pre-PCI code) in the length for userstring. This causes the code to walk on the stack. i.e. in the following call: WLFORM( badmsg, "Userstring '\?'") var^data^len := 0; CALL LOG^MESSAGE^( 1000, RTE^CDE^G, @badmsg, NET.MYNAME, LOG^INFO^L, @some^data, var^data^len ); would overwrite data and cause the satellite to dump. Change: Modified calls to subproc userstring in formatx, formatxtht, formatx^pci, formatxtht^pci to log empty data when a zero or negative length is passed. 11-02-28;15:14:06.004 \K9.$PPD2 ACI.PSAUTH.1000 1000 FROM: P1A^PRO RE: P1A^PRO Userstring-1 '' Userstring-2 '22222222222222222' ^^ In the sample message above a zero or negative message lenght is being passed for the display indicated by the "^^". Note: this occurs only with wlform formats "\?". See the BASE24 Application Programming Reference Manual section 5 "Event Logging Procedure Calls" for a description of the formatting character "\?". Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3552 SKELB - rel3^ver1^sutl16^20110315 15-MAR-11 Reference: Case Internal Symptom: - Messages generated by a satellite before the call to log^init (or loginit) display as ACI.SKEL.3700 (this is normal) but format with a message #0 and free form text. The msg looked like this: "ACI.SKEL.3700 0 11/03/15 09:13:17:088 (2) P1A^AUTH1 P1A^AUTH1 8102 0001_ SKEL Valid LCONF AFT-PAN-DIGITS param set to '094' Instead of this: "ACI.SKEL.3700 8102 FROM: P1A^AUTH1 RE: P1A^AUTH1 Valid LCONF AFT-PAN-DIGITS param set to '094'" Problem: SCR #3519 required insertion of four bytes into the internal message header and caused the display of some messages to be truncated. SCR #3540 corrected this in SKEL/SCRIBE code. However messages logged before the call to log^init/loginit are processed by network code, which still uses the old header. Change: Modified logic on log^messagex to send the old message header length when processing messages before the call to log^init/loginit. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3559 PREGEN - rel3^ver0^pre07^20110624 24-Jun-11 - rel3^ver1^pre02^20110624 Reference: CASE 01134933 Symptom: 1- PREGEN ABENDING due to insufficient primary/secondary extent sizes on large SPREFIX/PREMAP files 2- BUILDFILESIZE parameters did not change the primary/ secondary extent size for SPREFIX/PREMAP files. Problem: SCR 3177 hard coded the primary/secondary extent sizes for SPREFIX/PREMAP files and did not use the values specified in the BUILDFILESIZE parameters Change: Altered the code to use the values passed in the BUILDFILESIZE parameters so long as they are larger than the coded defaults Implementation: Install the new PREGEN object on the XPNET subvol and accelerate the code using the PREAXCL file. Dependencies: None \ SCR #3561 XNCGEN - REL3_VER1_XNCG08_20110630 30-JUN-11 Reference: Case #1087804 Symptom: XNCGNE abends. Problem: XNCGEN abends on a 16 character global name. Change: Added code to properly scan the name field and stop scanning at the end of the field. Implementation: Install new XNCGEN object file. Dependencies: None. SCR #3563 XPNET 3.0 POBJ - T3270-PRE (D30) 12 AUG 2011 09:33:49 08-AUG-11 - T6520-PRE (D30) 12 AUG 2011 09:33:27 SVIPF - rel3-ver0-ipf02-110810 XPNET 3.1 POBJ - T3270-PRE (D30) 12 AUG 2011 09:30:46 - T6520-PRE (D30) 12 AUG 2011 09:30:27 SVIPF - rel3-ver1-ipf02-110722 Reference: Case #1080118 Symptom: - Changes to IPF (Interchange Prefix File) are not written to the OMF (Online Maintenance File). Problem: This does not meet PCI requirements to audit file changes performed from Pathway. Change: Added logic to RQIPF and SVIPF to write IPF changes (ADD, UPDATE, DELETE) to the OMF using APPL-CDE "IL". Implementation: SCUP COPY updated IPF requestor to the XPNET.POBJ. Replace existing SVIPF object with new module. Dependencies: Both the IPF requestor and server must be installed at the same time. If only one is installed errors will occur and you will not be able to access or update any IPF records. SCR #3560 BASE - REL3^VER1^ELOG06^20110624 24-JUN-11 - REL3^VER1^BASE^REL29^20110624 BASE - rel3^ver0^rel78^110624 - rel3^ver0^elog08^110624 Reference: Cases 1107063 & 1126670 Symptom: - XPNET abnormally terminates with code 6307 in ELOG^IO. Problem: Application processes can send EMS events to XPNET to be generated (i.e. prior to calling LOG^INIT). There is logic in XPNET that attempts to determine the version of SKEL that built the event message and adjust the text length if it thinks the module id is present. If the length of the event message is less than 84 bytes this calculation could result in a negative text length which causes memory corruption in the SCRIBE logic. Once this happens any number of unpredictable results can occur. In the two cases reported the logic was attempting to add the manager token to the EMS event buffer in the SCRIBE logic. This failed due to the memory corruption and returned scribe error 9907. This caused the calling logic in XPNET to abend with dump code 6307. There was logic added by SCR1754 that was supposed to prevent this if the message length was less than the user^hdr^len (67 bytes). If so then don't subtract the user^hrd^len, just use the message length as the text length passed to SCRIBE. However in one case the logic subtracted an additional 17 bytes (new^skel^modid^len) which caused the text length passed to SCRIBE to be negative if the message length was less than 84 bytes. Change: Modified the logic added by SCR1754 to not adjust the text length passed to SCRIBE if user^hdr^len (67) plus the new^skel^modid^len (17) is greater than the message length. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3562 BASE - REL3^VER1^BASE^REL29^20110624 27-JUL-11 - REL3^VER1^PYLD03^20110727 BASE - rel3^ver0^rel78^110624 - rel3^ver0^pyld04^110727 Reference: 1127809 Symptom: - XPNET event #6354 logs saying "Content-length header value in XP-APPL-DATA CV is not valid". 11-06-27;04:22:03.023 \SYS.$P1AN ACI.XPNET.3000 6354 Station S1A^STA1 received an invalid request. HTTP function HTTP_ENV_CB_INIT, status=2 (invalid message), status-detail-1=32648 (Content-length header value in XP-APPL-DATA CV is not valid), status-detail-2=562. first 192 bytes: ......0:nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn: .... .....16:nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn: .... ..... Error at Offset nnn. - The Satellite Process who sent the above message may log the following. 11-06-27;04:22:03.029 \SYS.$P1AN ACI.SKEL.3700 8035 !!! FROM: P1A^PRO2 RE: P2A^PRO2 message returned, failure 122 Problem: If a response is received from an application where HTTP payload is involved, and that response does not contain a XP-APPL-DATA control vector, XPNET adds one with a content-length equal to the message header length. If that same message is routed to a second application who alters the message length but does not alter or replace the XP-APPL-DATA control vector, XPNET does not alter the content-length in the control vector so it is out of sync with the message header length. This causes event 6354 and the message to be failed back to the sender with failure code 122. Change: Changed XPNET to replace the content-length with the message header length in the above situation. Implementation: Install the new BASE file on the XPNET subvol. Rebind the NETWORK object using the NETB file. If on a RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Dependencies: None. SCR #3564 BASE - REL3^VER1^ONCF^LNK06^20110815 15-AUG-11 - REL3^VER1^BASE^REL29^20110624 BASE - rel3^ver0^rel78^110624 - rel3^ver0^oncf^lnk08^110815 Reference: Case #01134026 Symptom: - ADD LINK Link \SYS.NODE.P1A^LINK^P1B add failed, ppd attribute invalid - ALTER LINK , PPD \SYS.$PPD failed. Link \SYS.NODE.P1A^LINK^P1B ppd failed, ppd attribute invalid Problem: The logic validating the LINK process attributes on an ADD or ALTER was not working properly in one specific case. The logic to detect duplicate ppd names failed under the following configuration. For example a process was added with PPD $LINK1 (not fully qualified on system \PROD). The user then attempted to ADD a LINK process with PPD \PROD.$LINK or ALTER a LINK PPD to \PROD.$LINK. This was improperly flagged as a duplicate because the logic only compared the ppd's for 4 bytes. If the LINK PPD is not fully qualified (i.e. $LINK) it is not flagged as a duplicate. Change: Added new logic to also check last byte of the local PPD for a space before flagging the PPD as a duplicate and causing the ADD/ALTER LINK to fail. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3566 BASE - REL3^VER1^QUE07^20110902 02-SEP-11 - REL3^VER1^BASE^REL29^20110624 Reference: Case #01161348 Symptom: - XPNET abnormally terminates with a SIGNUM 11 in procedure QWRITE^CMD^IT^TIMER after issuing a CONTROL , QWRITE command. Problem: The logic to determine the size of the file did not account for the two byte "00" EOF marker. Under some combinations of message sizes and queue counts there was no slack in the file size calculated, so the logic trapped moving the EOF marker to an address just past the actual end of file. Change: Added an additional two bytes to the file size calculation to allow room for the EOF marker on files with no slack. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.1 only. SCR #3567 BASE - REL3^VER1^AUD05^20110929 29-SEP-11 - REL3^VER1^BASE^REL29^20110624 BASE - rel3^ver0^rel78^110624 - rel3^ver0^aud08^110920 Reference: Case #01151214, #01163953 Symptom: - XPNET abnormally terminates with a loop timer trap in procedure aud^io or aud^dispatch^msg after a "control node ,swaudit" command is executed (trap 4 in XPNET 3.0, signum 26 in XPNET 3.1). Problem: If an I/O is outstanding to the audit when a SWAUDIT command is executed, completion of that command is delayed until the I/O completes. If when that I/O completes another message is on the audit queue, a "while loop" that calls aud^dispatch^msg is executed to start the next I/O. Procedure aud^dispatch^msg exits without starting the I/O if it detects a SWAUDIT command is in progress, so the "while loop" continues endlessly. Change: Changed the above "while loop" so it does not execute if a SWAUDIT command is in progress. We fall out of that logic allowing a timer that is running to complete the SWAUDIT command. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3569 SKELB - rel3^ver1^sutl18^20111115 17-NOV-11 rel3^ver0^sutl37^20111115 Reference: Case 1125172, 1121686 Symptom: - Satellite abends. Stack walked on but global zero is intact. Verify from low-level debug: _$M3A1_a 0s,4 000333: .SK. .EL. . . . . _$M3A1_ Problem: SKEL expected that a logmessage using fixed length string would pass actual data. i.e. a wlform with "\\\\" is expected to pass 4 bytes) for variable length strings the code should be using "\*". If these were PCI messages, the code attempted to strip trailing spaces so it could accurately mask the last 'nn' bytes of data. When the message contained a blank field, and the preceding was also blanks, SKEL would calculate a negative length for the field which caused the stack to be overwritten. Change: Added code to reset the field length to zero when the field is all blanks. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. SCR #3570 SKELB - rel3^ver1^sutl18^20111115 17-NOV-11 - rel3^ver3^sutl37^20111115 Reference: Case 1134946, 1118806 Symptom: - Satellite abends, typically with a trap 2 (arithmetic overflow). The stack and global zero appear intact. The overflowed field appears to be in the wrong location. Problem: Logic in log^messagex could perform processing for the lmcfpci (200 bytes) when the customer was still using the old lmcf (153 bytes) format. This resulted in overlaying of a random address in the satellite's memory which will cause the field to overflow. Change: Corrected logic to process LMCFPCI/LMCF correctly. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3577 CTS - rel3^ver0^cts34^120430 30-APR-12 CTS - REL3^VER1^CTS12^20120430 Reference: Case #1197970 Symptom: - CTS external process reported invalid value for attribute STATION USERDATA. Station goes ABNORMAL. Problem: The buffer used for Userdata is only 64 bytes long. When using the -5 option this length can easily be exceeded as in this case. Initially the CTS\I code uses the configured station userdata seen in an INFO station detail from NCPCOM when starting the connection. This allows the initial attempt to succeed. Once the initial connection attempt is made the CTS/E will send back to CTS/I userdata with the default values. This is what is used in subsequent connection attempts. As stated above If using the -5 options, it is possible that the defaults along with the -5 information exceed the 64 bytes. This string is passed back to CTS/E from CTS\I and in this case the default of "BT1" is truncated at the 64 byte limit, it should have been "BT10-". The CTS\E code detects a invalid configuration and handles as an error condition. The string passed back from CTS\E is only supposed to be used for display in the status station detail in XPNET 3.1. In Xpnet 3.0 this information is displayed in the info station detail. In either case the code was overwriting the memory copy of the information from the NEF with this string. Change: correct the CTS\I code to only use the actual configured string from the NEF when ever initiating a connection. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3576 SKELB - rel3^ver1^sutl19^20120420 20-APR-12 - rel3^ver0^sutl38^20120420 Reference: Case 01189975, 01196559 Symptom: - Satellite abends, typically with a trap 2 (arithmetic overflow). The stack and global zero appear intact. The ZZSA shows that we were in #FORMATX^PCI/#FORMATXTHT^PCI (or similar proc) doing a length calculation. Problem: Logic in #FORMATX^PCI.FIXEDSTRING/#FORMATXTHT^PCI.FIXEDSTRING is trying to calculate a length by subtracting two address pointers using signed subtraction, but the addresses can go beyond the 32K boundary and then overflow occurs. E.g. adj^len := @first^null - @sptr[0]; Change: Corrected logic in 14 places to use unsigned subtraction to process the calculations correctly. E.g. adj^len := @first^null '-' @sptr[0]; Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3573 BASE - REL3^VER1^AUD06^20120417 17-APR-12 - REL3^VER1^ONCF^SYS18^20120417 - REL3^VER1^BASE^REL30^20120417 BASE - rel3^ver0^aud09^120517 - rel3^ver0^oncf^sys29^20120417 - rel3^ver1^rel80^20120417 Reference: Case 1185389 Symptom: - The Network traps with an arithmetic overflow while auditing to a large file (signum 8 for 3.1, trap 2 for 3.0). - The stack trace looks something like below: Num Lang Location ABEND Unknown TNS/R Code Space %h808F7A90 Unknown TNS/R Code Space %h808F88D8 Unknown TNS/R Code Space %h80961284 Unknown TNS/R Code Space %h80962004 0 TAL #DLIB_NM_TRAP_HANDLER.#953(DLIB06TS) + %HAI Unknown TNS/R Code Space %h7C36D7A0 1 TAL #AUDIT^MSG^PIECE.#1312(AUD06TS) + %H8I 2 TAL #AUDIT^MSG.#836(AUD06TS) 3 TAL #PROCESS^OUTPUT^TASK.WRITE.#13343(PROC14TS) 4 TAL #PROCESS^OUTPUT^TASK.#13752(PROC14TS) + %H3I 5 TAL #REL3^VER1^EXEC15^20120417.EXECUTE.#4367(EXEC15TS) + %H7I 6 TAL #REL3^VER1^EXEC15^20120417.#4791(EXEC15TS) Problem: Calculation of the file EOF yielded a negative result causing an arithmetic overflow trap. Change: Added edits for ADEXTENT and ADMAXEXTENTS to prevent them from creating an audit file with max size greater than aproximately 2.1 billion bytes. This will prevent the calculation of EOF from exceeding the limits of a positive INT32. To limit the file size to the above maximum, the product of ADEXTENT times ADMAXEXTENTS is not allowed to be greater than 1,030,000 pages. Because Guardian rounds these parameters in different ways for different hardware and disk formats, the file may be created with extents and max extents other than configured in XPNET. Configuring these params to the values that Guardian will round them to will allow for the maximum file size supported by XPNET, and will avoid confusion, but is not required. See H.P. documentation for details. ALTER NODE and ADD NODE commands will be rejected if an attempt is made to configure more than the above pages. If altering one field higher with the intent of altering the other lower, and the command is rejected, alter the lower value first then the higher one. Logic was added at NODE startup to modify the above values to their defaults if they were previously configured with more than the maximum mentioned. ADEXTENT defaults to 100, ADMAXEXTENTS to 16. Added a check to prevent an existing audit file with max size greater than 2,147,483,647 from being used (error 10, file already exists, is returned). In other cases auditing can use an existing file, so if error 10 is returned it is because of this file size check. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK). Dependencies: None. SCR #3579 BASE - REL3^VER1^EXEC15^20120417 01-MAY-12 - REL3^VER1^BASE^REL30^20120417 BASE - rel3^ver0^exec36^120417 - rel3^ver1^rel80^20120417 Reference: Internal (found while testing SCR3573) Symptom: - The Network traps with an illegal address reference at startup (signum 11). - The stack trace looks something like below: Num Lang Location ABEND Unknown TNS/R Code Space %h808F7A90 Unknown TNS/R Code Space %h808F88D8 Unknown TNS/R Code Space %h80961284 Unknown TNS/R Code Space %h80962004 0 TAL #DLIB_NM_TRAP_HANDLER.#953(DLIB06TS) + %HAI Unknown TNS/R Code Space %h7C36D7A0 1 TAL #CJ^CMD^HANDLED.#981(CJ05TS) + %H3I 2 TAL #ALTER^NEF.#7158(EXEC14TS) + %H43I 3 TAL #READ^NODE^RECORD.#19933(EXEC14TS) 4 TAL #FES^INIT.#6118(NSTP08TS) + %H2I 5 TAL REL3^VER1^EXEC14^20110516.#4499(EXEC14TS) Problem: At startup XPNET reads NEF records and fixes up invalid values by calling procedure "alter^nef". Procedure "alter^nef" makes a bad assumption that the record update was due to operator command, so it attempts to journal the "command". XPNET has not initialized all variables needed for journaling at this early point, so the trap occurs. Change: Added a check in "alter^nef" so it does not attempt to do command journaling when the reason for the NEF update is fixup during process startup. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK). Dependencies: XPNET 3.1 only. SCR #3580 BASE - REL3^VER1^EXEC15^20120417 01-MAY-12 - REL3^VER1^ONCF^SYS18^20120417 - REL3^VER1^BASE^REL30^20120417 BASE - rel3^ver0^exec36^120417 - rel3^ver0^oncf^sys29^20120417 - rel3^ver1^rel80^20120417 Reference: Internal (found while testing SCR3573) Symptom: - The Network traps with an arithmetic overflow when a "statistics node" command is issued or the "statistics interval" pops (while auditing is running and Node param AUDEXTENT is greater than 32767). - Signum 8 occurs for XPNET 3.1, trap 2 for XPNET 3.0. - The stack trace looks something like below if doing a "statistics node" command: Num Lang Location ABEND Unknown TNS/R Code Space %h808F7A90 Unknown TNS/R Code Space %h808F88D8 Unknown TNS/R Code Space %h80961284 Unknown TNS/R Code Space %h80962004 0 TAL #DLIB_NM_TRAP_HANDLER.#953(DLIB06TS) + %HAI Unknown TNS/R Code Space %h7C36D7A0 1 TAL #ONCF^SYSTEM.EXECUTE^STATISTICS^CMD. #14850(SYS17TS) + %H7I 2 TAL #ONCF^SYSTEM.#16062(SYS17TS) + %H3I 3 TAL #NET^CONTROL.#1174(ONCF05TS) + %H3I 4 TAL #ROUTE.#20638(EXEC14TS) + %H3I 5 TAL #RECEIVE^TASK.NETCMDINPUT.#14126(PROC14TS) 6 TAL #RECEIVE^TASK.#14616(PROC14TS) + %H4I 7 TAL #REL3^VER1^EXEC14^20110516.EXECUTE. #4369(EXEC14TS) + %H5I 8 TAL #REL3^VER1^EXEC14^20110516.#4636(EXEC14TS) - The stack trace looks something like below if the "statistics interval" popped: Num Lang Location ABEND Unknown TNS/R Code Space %h808F7A90 Unknown TNS/R Code Space %h808F88D8 Unknown TNS/R Code Space %h80961284 Unknown TNS/R Code Space %h80962004 0 TAL #DLIB_NM_TRAP_HANDLER.#953(DLIB06TS) + %HAI Unknown TNS/R Code Space %h7C36D7A0 1 TAL #LOG^STATISTICS.#18628(EXEC14TS) + %H7I 2 TAL #INT^COMP^IO.#15455(EXEC14TS) 3 TAL #REL3^VER1^EXEC14^20110516.EXECUTE.#4370 (EXEC14TS) + %H4I 4 TAL #REL3^VER1^EXEC14^20110516.#4636(EXEC14TS) Problem: Calculation of "Audit Percent Full" yields a large negative result causing an arithmetic overflow when AUDEXTENT is greater than 32767. Change: Modified the calculation for "Audit Percent Full" to treat AUDEXTENT as an unsigned integer. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK). Dependencies: None. SCR #3581 BASE - REL3^VER1^AUD06^20120417 10-MAY-12 - REL3^VER1^BASE^REL30^20120417 BASE - rel3^ver0^aud09^120517 - rel3^ver1^rel80^20120417 Reference: Internal (found while testing SCR3573) Symptom: - The Network traps with an arithmetic overflow while auditing to a large file (signum 8 for 3.1, trap 2 for 3.0). - The stack trace looks something like below: Num Lang Location ABEND Unknown TNS/R Code Space %h808F7A90 Unknown TNS/R Code Space %h808F88D8 Unknown TNS/R Code Space %h80961284 Unknown TNS/R Code Space %h80962004 0 TAL #DLIB_NM_TRAP_HANDLER.#955(DLIB06TS) Unknown TNS/R Code Space %h7C36D7A0 1 TAL #AUDIT^MSG^PIECE.LARGE^MSG^NOWAIT.#1046 (AUD05TS) + %HBI 2 TAL #AUDIT^MSG^PIECE.#1303(AUD05TS) 3 TAL #AUDIT^MSG.#836(AUD06TS) 4 TAL #AUD^DISPATCH^MSG.#1481(AUD05TS) 5 TAL #AUD^IO.#1828(AUD05TS) 6 TAL #REL3^VER1^EXEC14^20110516.EXECUTE.#4383 (EXEC14TS) + %H3I 7 TAL #REL3^VER1^EXEC14^20110516.#4793(EXEC14TS) Problem: While calculating whether the next write will start on a 2K boundary, an arithmetic overflow occurred. A modulo divide was being performed with the file EOF as the dividend and 2048 as the divisor, the intermediate result used by the compiler overflowed causing a trap. If the EOF is greater than 134,217,727 and AUDITIO is NOWAIT or WAIT this trap can occur, it does not happen if AUDITIO is BUFFERRED. To keep EOF below 134,217,727 the product of ADEXTENT times ADMAXEXTENTS must be less than or equal 65,535. Since Guardian may round extents up when the file is created that must be taken into consideration (see H.P. documentation for details). Change: Modified the calculation to shift the INT32 file EOF value left 21 bits, then right 21 bits effectively yielding the same result as the remainder of dividing by 2048. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK). Dependencies: None. SCR #3588 NETADRD - rel3^ver1^audr05^20120827 27-AUG-12 NETADRD - rel3^ver0^audr15^120827 Reference: Case 1205418 Symptom: NETADRD creates a saveabend whenever a bad output file name is entered. Problem: Sequential I/O procedure open^file defaults to abend when a bad file name is given. Change: open^file allows the passage of flag data to modify it's behavior. A 32 bit flag was added and passed to open^file to tell it not to abend on a bad file name and to pass back the error so the routing in NETADRD could log a message and go away gracefully. Implementation: Install the new NETADRD object file on the XPNET subvolume. Dependencies: None. SCR #3589 TCPSRV/SSLSRV - rel3_ver0_ssls23_120915 15-SEP-12 rel3_ver0_tcps52_120915 TCPCLI/SSLCLI - rel3_ver0_sslc32_120915 rel3_ver0_tcpc46_120915 rel3_ver0_tcpl39_120915 rel3_ver0_ctse26_120915 CTSE - rel3_ver0_ctse26_120915 CTSEPLS - n30ctse.ctse09ps CTSEPLO - n30ctse.ctse09po CTSEEC - n30ctse.ctse05ec CTSEEDDL - n30ctse.ctse05es CTSEETAL - n30ctse.ctse05et CTSEETCL - n30ctse.ctse05ea Reference: Case #1222522 Symptom: An XPNET node running on one HP node opens a port ( TCPSRV process ) running on a different HP node. Due to an Expand failure XPNET reports an error 249 which causes the station to recycle and transition back to the STARTING state, however, the corresponding remote TCPSRV->ATM TCPIP connection is still viable. Problem: When XPNET generates the error 249 EMS event on a station it can be assumed that the TCPSRV and XPNET are out of sync in regards to the XPNET open file number and the openers table in the TCPSRV. This is a result of the Expand error 249. Xpnet receives the 249 for each IO pending to the TCPSRV process. This causes XPNET to recycle the station causing a new open being sent (successfully) to the TCPSRV over expand. TCPSRV does not know about the Expand problem (it does not have an open to XPNET it just replies to XPNET). TCPSRV retains the already established connection to the ATM and will remain in this state until either the ATM does a shutdown of the connection or the TCPSRV is recycled. Communication to TCPSRV for this channel (XPNET open filenum - TCPSRV openers table - TCPIP connection ) is broken. If the XPNET station transitions from the STARTED state to STARTING, via the error 249 a new open (this will be a different filenum then the original open that the 249 was reported on) will occur and a new ACCEPT_CONN IO will be posted to the TCPSRV. In the case of ATM's and a configured RADDR this station will remain in starting because the ATM and TCPSRV still believes original connection is viable. Change: In order to control this situation a new Tell command has been implemented. This command must be issued from an NCPCOM on the same HP node that the TCPSRV is running. The Tell command will contain the HP node name and ppd name of the remote XPNET process that is associated with the Station (channel) that is in the out of sync condition. The command will also contain the symbolic name of the station. With this information the TCPSRV process will search the openers table, match on the Pri-Handle and station name then close the tcpip connection, reply to any outstanding IO's and initialize the opener table entry. This will allow the ATM to reconnect and will acquire the XPNET station that transitioned from STARTED to STARTING via the error 249 and opened the TCPSRV with a posting of an ACCEPT_CONN. ---------------------------------------------- *** New TELL command and Log Message Ex: NCPCOM> TELL EXTERNAL $SRV.#TCPRSET,"\XXXX.$P1AN S1A^SRX000" 12-09-05;17:14:02.908 \XXXX.$SRV ACI.XPCTSE.3000 1025 TELL TCPRSET COMMAND - STA (S1A^SRX000) STA NOT FOUND. NCPCOM> TELL EXTERNAL $SRV.#TCPRSET,"\XXXX.$P1AN S1A^SRV000" 12-09-05;17:12:23.841 \XXXX.$SRV ACI.XPCTSE.3000 1026 TELL TCPRSET COMMAND - STA (S1A^SRV000) STA RESET. ----------------------------------------------- Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Install the new CTSEPLS file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None. SCR #3583 --XPNET 3.1-- EOF LAST MODIFIED 18-JUN-12 OCAPATH - n21path.oca01as 6928 22JUN2012 14:16 OCAPWS - n30pws.oca01as 16430 22JUN2012 14:24 OCAQFI - n30qfi.oca01as 7410 22JUN2012 14:28 --XPNET 3.0-- EOF LAST MODIFIED OCAPATH - n21path.oca01as 6928 22JUN2012 14:16 OCAPWS - n30pws.oca01as 16430 22JUN2012 14:24 OCAQFI - n30qfi.oca01as 7410 22JUN2012 14:28 OCAAPPL - u30alib.oca02as 11272 26JUN2012 13:04 OCAMQSI - n30mqsi.oca01as 7582 26JUN2012 13:16 OCANCP - s30ncp.oca01as 11254 26JUN2012 12:54 OCANCPI - s30ncpi.oca01as 14368 26JUN2012 12:58 OCANET - n30base.oca01as 6708 26JUN2012 12:49 OCANETAD - n30audr.oca01as 6696 26JUN2012 12:45 OCANLIB - n30nlib.oca01as 7082 26JUN2012 12:52 OCAPREG - s30pre.oca01as 6852 26JUN2012 13:08 OCASKELB - n30sutl.oca02as 11510 26JUN2012 13:13 Reference: 1207310 Symptom: - When runing OCA tacl routines provided by ACI, amessages similar to the below log and the job aborts. PATH object is being accelerated with OCA. OCA /out $S.#OCA.PATH, name / PATH, output_file PATHA, obey ZZOCA07 *** ERROR *** OCA failed with completion code 1 See $S.#OCA.PATH for error information. - Spooler output from the OCA job contains output similar to the below. *** Warning 15: Procedure REL3_DLIBB69_20NOV95 at offset 01547 in file PATH inherits register 7. *** Warning 15: Procedure DUMP at offset 03144 in file PATH inherits register 7. Problem: HP modified their OCA product causing new warnings. HP solution 10-110309-6569 already exists and they are considering a fix (see that solution for details). HP looked at one of our object files and said these particular warnings were safe to ignore. Change: Added "INHERITSR7" statements to the OCA files (listed above) to work around the issue while HP decides whether to make a fix. Implementation: Install the new OCA files on the XPNET subvol. If previous executions of OCA failed, purge the intermediate "xxxA" files (i.e. PATHA, PWSA, QFIA). Execute the new OCA files. Dependencies: None. SCR #3591 BASE - REL3^VER1^BASE^REL32^20120925 25-SEP-12 - REL3^VER1^ONCF^DEST07^20120925 - REL3^VER1^ONCF^STA09^20120925 - REL3^VER1^ONCF^PRO12^20120925 - REL3^VER1^ONCF^SYS20^20120925 - REL3^VER1^ONCF^CJ06^20120925 - REL3^VER1^DCOM07^20120925 - REL3^VER1^PROC15^20120925 - REL3^VER1^GATE14^20120925 - REL3^VER1^EXEC16^20120925 GLOBAL - N31GLBL.GLBL17TG - N31GLBL.MSG08TG - N31GLBL.MSG08DC - N31GLBL.MSG08DD - N31GLBL.MSG08DM - N31GLBL.MSG08DS - N31GLBL.MSG08DT DDLC - S31SDDL.SDDL08DC DDLCOB - S31SDDL.SDDL08DX DDLFUP - S31SDDL.SDDL08DZ DDLS - S31SDDL.SDDL08DS DDLTAL - S31SDDL.SDDL08DT NCPDC - S31NCPI.NCPI11DC NCPDCOB - S31NCPI.NCPI11DX NCPDCB74 - S31NCPI.NCPI11DV NCPDDDL - S31NCPI.NCPI11DS NCPDFUP - S31NCPI.NCPI11DZ NCPDTAL - S31NCPI.NCPI11DT NCPDTCL - S31NCPI.NCPI11DA NETDDLS - N31GLBL.GDDL06DS NETDC - N31GLBL.GDDL06DC NETDTAL - N31GLBL.GDDL06DT NETDFUP - N31GLBL.GDDL06DZ NCPCOM - REL3^VER1^NCPC22^20120925 - REL3^VER1^NCPL21^20120925 - REL3^VER1^RLBK05^20120925 - S31NCPL.PREL11TG - S31NCPL.PARS14TG - S31NCPL.NCPL10TG - S31NCPL.NCPL11DS SVNCPI - REL3^VER1^REL19^20120925 - REL3^VER1^NCP17^20120925 - REL3^VER1^OBJ12^20120925 - S31NCPI.NCPRSP08 - S31NCPI.NETCMD06 - S31NCPI.NETRSP07 SVNCS - REL3^VER1^SNCS18^20120925 - REL3^VER1^NCPL21^20120925 - S31NCPL.PREL11TG - S31NCPL.PARS14TG - S31NCPL.NCPL10TG - S31NCPL.NCPL11DS SVNCSP - SVNCSP-31-10 - SVTAB-A-31-08 - SVTAB-B-31-03 NCSPREPT - NCSP-REPORT-REL31-08 - SVTAB-A-31-08 - SVTAB-B-31-03 SVNCSP24 - SVNCSP-NET24-31-11 - SVTAB-A-31-08 - SVTAB-B-31-03 NETCJRD - REL3^VER1^CJRP09^120925 Reference: Case #01224934 Symptom: - Customer was unable to control service based routing as desired for inbound station messages. See Option 1. - Under EPS there was no way to temporarily prevent an application or group of application processes from receiving messages for one or more specific services See Option 2. - Without significant code changes to the application the customer was not able to restrict message routing to a single XPNET node for messages routed to a service. See Option 3. Problem: For messages inbound from a station new configurable attributes must be added as well as new logic to set the specific fields in the XPNET message header that affect the service based routing logic. Under EPS, the IS object module is created by linking together all of the various functional components. These modules dynamically register the service(s) they provide to XPNET. The service name is hard coded, so unless code changes are made to modify the service name, every IS process in the system provides the same service(s). In addition the logic invoked in the IS module is based on these hard coded service names. So when a message is read from XPNET, the value in msg^sym^dest determines which logic is invoked in the IS application. Service based routing was designed to be context free, so if all of the local IS service providers are not available XPNET will route the message to a service provider on another XPNET Node (if the service spans multiple nodes). Again under EPS the IS application process dynamically registers all of the service(s) it provides based on the modules it has been built with and the only way to change this is to not LINK in specific modules and maintain multiple object files. However, once the object is built and started there is no way to control this. There is no way to temporarily stop messages from being sent to a specific service [at the process level] while still allowing messages for the other services. It is either ALL or NONE (stop the process). Change: Several changes were done to address the various issues. Please note these changes are bundled together and released at the same time, however, they are not dependent on each other. They can be used separately or together depending on what works best in your environment. OPTION 1: Added a new XPNET message header flag: msg^service^force^local = (msg[22]).<0># msg^service^force^local^(x) = x[22].<0># Added two new station attributes: SBRDISTGLOBAL ON/OFF SBRFORCELOCAL ON/OFF These values will be used to set the following bits in the XPNET message header on all messages sent from this station to a destination. The settings of these will affect the service based routing algorithm. They are mutually exclusive and only one can be set to ON at the station. SBRDISTGLOBAL -> msg^service^dist^global (msg[53].<3>) SBRFORCELOCAL -> msg^service^force^local (msg[22]).<0>) The msg^service^dist^global bit has precedence. If this is set msg^service^force^local will not be examined. When msg^service^dist^global is set it tells the service based routing logic to round robin route the message(s) evenly across the entire system and removes the local node bias in the algorithm. If msg^service^dist^global is false then the service based routing logic will examine msg^service^force^local. If this is true the external service providers are not considered as a viable destination. The only exception to this is if there are no local service providers. If there is at least one local provider (available or not (i.e. stopped/above SMT/etc)) the message will be routed to a local provider (even if the local providers are not available/down and there are remote providers available). If there are no local providers then the message will still be routed to a remote service provider. Otherwise the message would have to be queued in the USQueue which would cause ALL new messages routed to this service to queue in the USQueue until there was a local service provider to take the "force local" message. This would prevent any new messages from being able to be processed until a local provider is added. OPTION 2: Added two new CONTROL PROCESS commands: CONTROL PROCESS , REGISTER CONTROL PROCESS , UNREGISTER With these commands an operator can add or remove a dynamic service to/from the specified process. When these commands are issued from NCPCOM/NCS it is exactly the same as if the process sent a #REGISTER or #UNREGISTER message to XPNET. This will allow an operator to add a dynamic service to a process (with no code changes in the application) and also remove a single service from the specified process (again with no code changes). So for example you want a specific IS process to temporarily not receive messages for service INTFVISA you could UNREGISTER this process as as an INTFVISA service provider (from XPNET) and allow all of the other dynamic services this process provides to continue to process. When you want to reset this you could stop/start the process or issue the REGISTER control command to add it back. In addition you can add as many dynamic services as you want to a process without making any code changes. However, just like a "normal" dynamic service it will be deleted when the process stops/abends. So this CONTROL PROCESS , REGISTER would have to be reissued if the process stops for some reason. OPTION 3: Added two new attributes to the DEST object. ALIAS REPLACEALIAS ON/OFF With applications like EPS, each of the components register with XPNET a hard coded service name which is the same across the entire system (without code changes and multiple objects). With the addition of the ALIAS attribute associated with a DEST, you can create a configurable node specific service associated with the application dynamic service. So for example you have an object on P1A^NODE that registers service AUTH you would ADD DEST AUTH with an ALIAS of NODEA-AUTH ( for example ) and REPLACEALIAS OFF on P1A^NODE. Then when the process sends the #REGISTER AUTH to XPNET, both service AUTH and NODEA-AUTH will be dynamically registered for this process. On P1B^NODE you would add a DEST object with an ALIAS of NODEB-AUTH with REPLACEALIAS OFF. So any object under P1B^NODE that #REGISTERS AUTH will provide both AUTH and NODEB-AUTH. If the application #UNREGISTER's AUTH, XPNET will also unregister the ALIAS service. It is just as if the application also sent a #REGISTER NODEA-AUTH message. The ALIAS service is propagated to all of the other XPNET nodes (connected via a started LINK) just like any other service. If REPLACEALIAS is OFF [for DEST AUTH] then messages can be routed to both AUTH and NODEA-AUTH ( for example ) and be processed by the application. If the application is dependant on what is in the symbolic destination (like EPS) then the logic will not function correctly if NODEA-AUTH is in the symbolic dest of the message. This is where the REPLACEALIAS attribute comes into play. To make this work correctly ADD DEST NODEA-AUTH with an ALIAS of AUTH and REPLACEALIAS ON. If this is the case then before the message (routed to NODEA-AUTH) is written to the application, msg^sym^dest is changed to the NODEA-AUTH alias "AUTH" (just like how REPLACEDEST on the PROCESS) If REPLACEALIAS were ON for DEST AUTH, then msg^sym^dest in the messages routed to AUTH would be changed to NODEA-AUTH before they are written to the application. So you would have the following dests configured. DEST AUTH, ALIAS NODEA-AUTH, REPLACEALIAS OFF DEST NODEA-AUTH, ALIAS AUTH, REPLACEALIAS ON With this set up messages can be routed to both NODEA-AUTH and AUTH and when the application reads the message the symbolic dest will be AUTH (regardless of where the source object routed it). NOTE: PROCESS attribute REPLACEDEST has precedence and if this true, the msg^sym^dest will be changed to processes symbolic name and DEST REPLACEALIAS will not be examined. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Update NCSP for the new commands if using ONCF security. Add a DEST with an ALIAS and REPLACEALIAS OFF for any service you want to have a node specific service added when it is dynamically registered. If the application depends on the value in msg^sym^dest to determine what internal logic to invoke then also ADD DEST with an ALIAS and REPLACEALIAS ON. ALTER STATION , SBRDISTGLOBAL ON if you want messages from this station to be evenly distributed across all XPNET nodes with a service provider and avoid the local node bias. ALTER STATION , SBRFORCELOCAL ON if you want prevent messages from this station to be sent to a service provider on other XPNETS (as long as there is at least one local provider ( available or not ). Application processes can also set msg[22].<0> -> msg^service^force^local to true. To add a dynamic service to a process: CONTROL PROCESS , REGISTER To remove a dynamic service from a process: CONTROL PROCESS , UNREGISTER Dependencies: XPNET 3.1 only. SCR #3592 NCPCOM - REL3^VER1^NCPC23^20121029 29-OCT-12 NCPCOM - rel3^ver0^ncpc44^121029 Reference: Case #1231172 Symptom: - The "getversion" command returns incorrect information after the "more" prompt. Problem: The "getversion" command is different from most in that it defaults to "node *" and does not allow additional params or wildcarding. Because of that difference, certain global variables used to process the request after the more prompt were not set. Workaround: Issue command "info node *" immediately before the "getversion" command. Change: When processing the "getversion" command set certain global variables as other commands (like info) do. Implementation: Install the new NCPCOM on the XPNET subvol. Dependencies: None. SCR #3594 NCPCOM - REL3^VER1^NCPC23^20121029 14-NOV-12 NCPCOM - rel3^ver0^ncpc44^121029 Reference: Internal Symptom: - The "getversion" command may return only one response per NCPCOM prompt at times. Problem: Field request.static.max^resps determines the number of responses returned at a time. Global fields determine the setting of that field, and those globals were not initialized by the "getversion" command. Depending on how the previous command set the global fields this problem can result. Change: Initialized the global fields that determine the setting of request.static.mas^resps for the "getversion" command. Implementation: Install the new NCPCOM on the XPNET subvol. Dependencies: None. SCR #3596 SKELB - rel3^ver0^SUTL39^20121219 30-NOV-12 SKELLIST SKELB - rel3^ver0^SUTL20^20121219 SKELLIST Reference: Case 01235040 Symptom: Changing severity code using a PCI LMCF doesn't work. Problem: Logic is not using the LMCFPCI record when modifying the severity code. Change: Corrected logic to use the proper LMCF. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None. SCR #3599 XNCGEN - REL3_VER1_XNCG09_20130130 30-JAN-13 Reference: Case 1245505 Symptom: When there are 56 processes in the XML file and the last process is accessed XPNET dumps and if a xncdetail is done on that process NCPC dumps. Problem: The XNCGEN program was not accounting for bytes that are added when the data pointer is on an 8 byte boundary. I have added code to correctly account for these bytes. Change: Added code to use the current data pointer plus the sized needed when checking whether to resize the segment. This will take into account data that was accumulated but not accounted for when the pointer is on an 8 byte boundary when setting the data pointer. Implementation: Install new XNCGEN object file. Dependencies: None. SCR #3593 SKELB - rel3^ver1^sutl21^20130104 07-NOV-12 SKELLIST SKELB - rel3^ver0^sutl40^20130104 SKELLIST Reference: Case #01233609 Symptom: N/A Problem: - Both Visa and AMEX have amended the allowed values for the PAN lengths for their cards. - The SPROUTE routing algorithm only allows for Visa cards with a PAN length of 13 or 16. - The routing algorithm for AMEX did not include a check for PAN length. - The routing algorithm for Mastercard was changed to allow for different PAN ranges. Change: The Visa routing algorithm was modified to identify the card if the PAN length is between 13 and 19 (inclusive). Previous Algorithm: if (account^number^length = 16 or account^number^length = 13) and account^number = "4" then found := true; Updated Algorithm: if (account^number^length >= 13 and account^number^length <= 19) and account^number = "4" then found := true; Changed the logic to identify the card as AMEX if the PAN length is between 15 and 19 inclusive. Previous Algorithm: if account^number = "34" or account^number = "37" then found := true; Updated Algorithm: if (account^number = "34" or account^number = "37" ) and (account^number^length >= 15 and account^number^length <= 19) then found := true; Changed the Mastercard/Inas logic to also identify the card if the PAN starts with 50 or 56 through 59 and the PAN length is between 12 and 19 inclusive. Previous Algorithm: if account^number >= "51" and account^number <= "55" then found := true; Updated Algorithm: if ( account^number >= "51" and account^number <= "55") or ((account^number = "50" or (account^number >= "56" and account^number <= "59")) and (account^number^length >= 12 and account^number^length <= 19 )) then found := true; Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None SCR #3603 NCPCOM - rel3^ver1^ncpc24^20130226 26-FEB-13 rel3^ver1^ncpl22^20130226 SVNCS - rel3^ver1^sncs19^20130226 rel3^ver1^ncpl22^20130226 Reference: Case 1248760 Symptom: When doing a QVIEW with DETAIL option, NCPCOM abended. Problem: It abended on a one byte message that had an inconsistent message header. The message text pointer in the header pointed to the message correctly, but the code was relying on the message being at the header size plus message userdata size offset. Change: Modified the code to use the message text pointer field in the header. Implementation: Install the new NCPCOM and SVNCS objects. Dependencies: None SCR #3605 BASE - REL3^VER1^BASE^REL33^20130501 01-MAY-13 - REL3^VER1^PROC16^201305010501 - REL3^VER1^QUE08^201305011 GLOBAL - N31GLBL.GLBL18TG^20130501 BASE - REL3^VER0^BASE^REL82^20130501 - REL3^VER0^PROC40^20130501 - REL3^VER0^QUE18^20130501 GLOBAL - N30GLBL.GLBL44TG Reference: Case 1450121 Symptom: All processes on a node abended and were placed in the ABNORMAL state. Problem: Messages with a bad field were sent by Mastercard and caused an application process to abend. The process abended without replying to the message, XPNET rerouted that message to a second process. That process also abended. In this situation, the message stays queued to that process and operator intervention is needed to remove the message from the queue and to restart the process. Several bad messages were sent and all of the processes abended. Change: There are "switch bits" defined in XPNET that a customer can set on ( sbit ) and turn off or reset ( rbit ) using a NCPCOM CONTROL command. These switch bits are used to direct the XPNET node to do special processing. Two switch bits that can now be set via operator intervention. These switch bits have the following effects: Switch Bit 30) When set on, this will cause XPNET to not reroute the transaction to a second process. The transaction will stay with the first application process that tries to approve it. That application process will end up in the abnormal state, as it does today, and the message will be located in it's queue. Operator intervention is required to deal with the message and re-start the process. This is an improvement from the current methodology, in that it only takes down one process per bad message. Switch Bit 31) When set on, this will cause XPNET to not reroute the transaction to a second process. The transaction, after having caused the application process to abend, will be placed in XPNET's internal diagnostic destination queue called #DIAG-DEST, thus avoiding the need for operator intervention (pop, purge, qwrite) to remove the "bad" message. These messages can be retrieved using several methods explained in Appendix E of the XPNET Network Control Operations Guide. Using switch bit 31 will allow XPNET to restart the application process automatically ( if the STARTUP is configured as AUTOMATIC ) and it will not end up in the abnormal state. It should be noted that if either of these switch bits are turned on with the sbit command, any time the node(s) are brought down and back up, the sbit command will need to be executed again. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.0 and 3.1. SCR #3606 BASE - REL3^VER1^BASE^REL33^20130501 16-MAY-13 - REL3^VER1^GATE15^20130516 BASE - rel3^ver0^rel82^130516 - rel3^ver0^gate34^130516 Reference: Case #01249287 Symptom: - XPNET Node abended with a trap #00011 in procedure DEST^DEACTIVATE^SERVICE. Problem: When a process stops/abends, its dynamic services are deactivated and deleted. In this situation the process was in inspect which changed the timing of the termination logic which resulted in the code attempting to deactivate a service that was previously deactivated and deleted. Procedure DEST^DEACTIVATE^SERVICE did not handle this correctly. Some of the variables on the stack were still pointing at the memory locations that had been deleted. This allowed the logic to partially process the deactivate but then failed attempting to access an invalid address. Change: Modified DEST^DEACTIVATE^SERVICE to return out the procedure if there are no services associated with the process or station. This will prevent the logic from attempting to deactivate this service and access the stale variables. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3607 BASE - REL3^VER1^ONCF^STA10^20130517 17-MAY-13 - REL3^VER1^ONCF^LIN04^20130517 - REL3^VER1^BASE^REL33^20130501 BASE - REL3^VER0^ONCF^STA09^20130517 - REL3^VER0^ONCF^LIN10^20130517 - REL3^VER0^REL82^130516 Reference: Case #01449279 Symptom: - NETWORK process abends if the following happens: a) A CTS line experiences one of a small number of errors (e.g. 201/60/17) b) the STATION or STATION and LINE are immediately stopped and deleted c) the TASK^REOPEN^TIMER^EXP timer expires The actual ABEND is different depending on whether just the STATION is deleted, or both the STATION and the LINE are deleted. The stack would look similar to the following if both the STATION AND the LINE are deleted (before the REOPEN timer expires): 0 TAL #PROGRAMMATIC^DUMP.#1117(DLIB06TS) + %HAI 1 TAL #NETDUMP.#18894(EXEC16TS) + %H3I 2 TAL #REL3^VER1^EXEC16^20120925.EXECUTE.#4377(EXEC16TS)+%H4I 3 TAL #REL3^VER1^EXEC16^20120925.#4636(EXEC16TS) The stack would look similar to the following if just the STATION is deleted (before the REOPEN timer expires): 0 TAL #DLIB_NM_TRAP_HANDLER.#953(DLIB06TS) + %HAI Unknown TNS/R Code Space %h7C36D7A0 1 TAL #CTS^IO.#3551(CTS12TS) + %H2I 2 TAL #CTS^DATACOM.#2342(CTS12TS) 3 TAL #INTERUPT^LINE.#6101(DCOM07TS) + %H6I 4 TAL #REL3^VER1^EXEC16^20120925.EXECUTE.#4379(EXEC16TS) 5 TAL #REL3^VER1^EXEC16^20120925.#4636(EXEC16TS) Problem: - The TASK^REOPEN^TIMER^EXP timer isn't canceled when the CTS STATION and/or LINE is/are deleted, following a retryable error (e.g. 201/60/17) but before TASK^REOPEN^TIMER^EXP timer expires. Change: Added logic to cancel the TASK^REOPEN^TIMER^EXP when 1) when the CTS line is deleted. 2) when the CTS line is disabled. 3) when the CTS station is deleted. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) Dependencies: None. SCR #3609 BASE - rel3^ver1^rel20^20130708 08-July-13 - rel3^ver1^mem01^20130708 - rel3^ver1^ut03^20130708 - rel3^ver1^obj13^20130708 Reference: Case 01465336 Symptom: NCPI abended due to too many DESTs Problem: The dest tree had a max size of 20,000 but the amount was exceeded in a test environment which caused the system to abend. Change: the max^nodes were increased from 20,000 to 100,000 to allow for the potential for the increased volume. Implementation: Install the new SVNCPI object. STOP and START the NCPI processes (STOP<$ncpi> from TACL or via a DELIVER NODE ,"ABORT-NCPI" ncpcom command) Dependencies: XPNET 3.1. SCR #3610 BASE - REL3^VER1^ELOG07^20130801 01-AUG-13 - REL3^VER1^BASE^REL34^20130805 Reference: Case #01462365 Symptom: - 13-06-25;17:37:00.361 \xxxxx.$xxxx ACI.XPNET.3100 15 Process P1A^xxxx^xx abended Previous STARTED, Current ABNORMAL Problem: When setting event flags of PROABNORMAL and PROUNAVAIL to 'OFF' at the process level, these events do not properly override what is set at the node level. Customer wants ability to shutoff the above EMS log message at the at the process level but was not able to. work around that was given until problem could be fixed was: "set the PROABNORMAL to OFF at the node level and set the PROUNAVAIL to OFF at the process level." Change: Changed the logic in "elog^generate^object^unavail' of ELOG07TS to properly examine the "process" PROABNORMAL event flag rather than the "node" event flag. Changed logic to have the process level attributes to be checked for settings that would point to the NODE or ON. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.1 only. SCR #3611 LLIB - $DATA01.L10LLIB.LLIB04 16-SEP-13 Reference: Case 01475877 Symptom: - Node ABENDs with Trap #00026 usually near midnight. Problem: - The abend was caused by a loop developing in a routine that generates random numbers (LLIB_GET_RANDOM32) for various functions. The XPNET NETWORK process chooses a seed value for the random number generator that in certain rare situations can cause this code to go into a loop. The chances of this happening are millions to one, and when needed this piece of code usually runs at midnight. A loop can happen where temp16[0] = 0 or temp16[1] = 0 indefinitiely... ABEND looks like this: 0 TAL #DLIB_NM_TRAP_HANDLER.#953(DLIB06TS) + %HAI Unknown TNS/R Code Space %h7C36D7A0 1 TAL #LLIB_GET_RANDOM32.#434(LLIB03TS) + %H2I 2 TAL #LLIB_LI_CB_INIT.#662(LLIB03TS) 3 TAL #$DATA01.L10LLIB.LSEC04TS.XPCONTROLS.#3801(LSEC04TS) 4 TAL #INT^COMP^IO.#15801(EXEC16TS) 5 TAL #REL3^VER1^EXEC16^20120925.EXECUTE.#4370(EXEC16TS)+%H4I 6 TAL #REL3^VER1^EXEC16^20120925.#4636(EXEC16TS) Change: - Added logic to detect a loop and force LLIB_GET_RANDOM32 to get a new juliantimestamp that will give a non-zero result that will end the looping. Implementation: - Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: 3.1 Only. SCR #3616 SVNCP - rel3^ver0^ncp18^131111 11-NOV-13 SVNCP - rel3^ver1^sncp05^20131111 Reference: Case #1500463 Symptom: SVNCP abends with trap #1046 in NCP_INIT with a stack trace similar to the below. Variable "error" in scope 1 (ncp_init) has a value of 3. Num Lang Location ABEND 0 TAL #NCP_DUMP.#9868(NCP17TS) + %5I 1 TAL #NCP_INIT.#10034(NCP17TS) 2 TAL #REL3^VER0^NCP17^060601.#1695(NCP17TS) Problem: Guardian procedure "process_getinfo_" is called requesting a process descriptor and the call fails with error 3 (parameter bounds error). The error happens because the buffer we provide isn't large enough to handle this particular process descriptor. We do not expect this error and force trap 1046. Change: Increased the size of the buffer passed to process_getinfo_. Used ZSYS^VAL^LEN^PROCESSDESCR for the length of that buffer as suggested by HP Knowledge Base solution mmr_ns-gcsc19950. Implementation: Install new SVNCP modules on the XPNET subvolume and stop all NCP server processes from TACL. Dependencies: None. SCR #3624 NCPCOM - REL3^VER1^NCPC25^20140228 28-Feb-14 - REL3^VER1^NCPL23^20140228 - S31NCPL.PARS15TG - REL3^VER2^NCPC02^20140228 - REL3^VER2^NCPL02^20140228 - S32NCPL.PARS02TG Reference: Case #01518073 Symptom: NCP returns an error on a "DELIVER DEST" when "FAIL" is used as a valid filter option Problem: Define destdeliverlist^d in PARS14TG was using ncp^vty^mod^fail when it should have been using ncp^vty^destfilt^fail . Change: Updated to use correct filter definition for FAIL Dependencies: XPNET 3.1 and 3.2 only. SCR #3636 NETDMPRD - rel3^ver1^nd1400^20140514 14-MAY-14 rel3^ver1^nd2800^20140514 rel3^ver2^nd0000^20140514 Reference: Internal Symptom: - NETDMPRD traps before producing any output. - Command "bt" from EINSPECT shows something like below: (eInspect 2,1555):bt #0 0xfffffffff90283d0 in UNKNOWN_FUNCTION_NAME_ () #1 0xfffffffff9091bf0 in UNKNOWN_FUNCTION_NAME_ () #2 0xfffffffff0ccb790 in UNKNOWN_FUNCTION_NAME_ () #3 0xfffffffff0ccd050 in UNKNOWN_FUNCTION_NAME_ () #4 0xfffffffff0cc3620 in UNKNOWN_FUNCTION_NAME_ () #5 0xfffffffff0ccfa90 in UNKNOWN_FUNCTION_NAME_ () #6 0xfffffffff0cd0700 in UNKNOWN_FUNCTION_NAME_ () #7 0xfffffffff0ccece0 in UNKNOWN_FUNCTION_NAME_ () #8 0xfffffffff90607e0 in UNKNOWN_FUNCTION_NAME_ () #9 0x70017520:0 in SALU_SALVAGE_DATA (PARAMETER_MASK$= -2305843009213693952, SALUCB_=0x6ffffa38, SAVEFNAME=, SAVEFNAMELEN=, SEGMAXID1=0, SEGMAXSIZE2=0, SEGMAXID3=0, SEGMAXSIZE3=0, MIPS_NATIVE_GLBL_LEN=0) at \K9.$DATA01.U31SALU.SAL200TS:961 #10 0x70004470:0 in PROCESS^DUMPFILE^MEMORY ( EXT^DUMP^FILE=0x6fffff30 "$VOL.SUBVOL.ZZSA1234", DUMP^LEN=0x6fffff50, TERM^NUM=0x6ffffe08) at \K9.$DATA01.N31DMQE.DMQE04TS:546 #11 0x700034c0:0 in REL3^VER1^DMQE04^20061030 () at \K9.$DATA01.N31DMQE.DMQE04TS:309 Problem: The length of Globals changed from one update level to another, DMQE needs to know the exact length to function properly. Change: Created new development naming conventions that allow different update levels of DMQE depending on the length of Globals. Implementation: Install the new DMQE object file on the XPNET subvolume. Dependencies: None. SCR #3648 SKELB - rel3^ver2^sutl02^20150126 26-JAN-15 SKELLIST SKELB - rel3^ver1^sutl22^20150126 SKELLIST SKELB - rel3^ver0^sutl41^20130104 SKELLIST Reference: Case #01826117 Symptom: N/A Problem: - The routing algorithm for Mastercard was changed to allow for different PAN ranges. Change: The Mastercard routing algorithm was modified to allow fo the new pans (222100-272099) Previous Algorithm: if ( account^number >= "51" and account^number <= "55") or ((account^number = "50" or (account^number >= "56" and account^number <= "59")) and (account^number^length >= 12 and account^number^length <= 19 )) then found := true; Updated Algorithm: if ( account^number >= "51" and account^number <= "55") or ( account^number >= "2221" and account^number <= "2720") or ((account^number = "50" or (account^number >= "56" and account^number <= "59")) and (account^number^length >= 12 and account^number^length <= 19 )) then found := true; Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None SCR #3645 SVNCS - REL3^VER1^SNCS21^20140925 15-OCT-14 - $data01.s31ncpl.ncpl13d* - $data01.s31ncpl.ncpl11tg SVNCS - REL3^VER2^SNCS03^20150223 - $data01.s32ncpl.ncpl03d* - $data01.s32ncpl.ncpl05tg $DATA01.S31NCS.NCS04 POBJ - T3270-N24NCS 14336 (D30) 07 JAN 2015 14:34:16 - T3270-NCS 14336 (D30) 07 JAN 2015 14:33:41 - T6520-N24NCS 14336 (D30) 07 JAN 2015 14:34:00 - T6520-NCS 14336 (D30) 07 JAN 2015 14:33:24 $DATA01.S32NCS.NCS02 POBJ - T3270-N24NCS 14336 (D42) 26 FEB 2015 08:26:08 - T3270-NCS 14336 (D42) 26 FEB 2015 08:25:42 - T6520-N24NCS 14336 (D42) 26 FEB 2015 08:25:55 - T6520-NCS 14336 (D42) 26 FEB 2015 08:25:29 Reference: Cases: 01718873, 01771291 Symptom: When using NCS screen the output message for some messages were not displayed properly: - the output message is displayed as one text stream (missing end-of-line charac ters: 0D 0A hex), - the output message is missing characters in the last column. Problem: DELIVER, WAIT responses are written to the screen for 80 bytes on each line. This works fine for NCPCOM, which can show the entire line. However, due to SCOBOLX screen restrictions the NCS display line can only be 79 bytes per line. The logic to format the response did not account for this, causing the 80th character on each line to be truncated if the response data was greater than 79 bytes. Change: Added logic to format DELIVER, WAIT response data at 79 bytes per line for the NCS requestor. Implementation: Install updated SVNCS on the XPNET subvol. SCUP COPY the new NCS requestor(s) to the XPNET POBJ file. Dependencies: None. SCR #3652 SKELB - REL3^VER2^SUTL03^20150420 20-APR-15 SKELLIST - $data01.n32sutl.sutl03tl SPRT00 - REL3^VER2^SPRT00^20150420 SPRT00B - SPROUTE BIND FILE SPRT00BC - SPROUTE BIND OBEY FILE SPRTEXP - SPROUTE EXPLAIN FILE SKELB - REL3^VER1^SUTL24^20150420 SKELLIST - $data01.n31sutl.sutl24tl SPRT00 - REL3^VER1^SPRT00^20150420 SPRT00B - SPROUTE BIND FILE SPRT00BC - SPROUTE BIND OBEY FILE SPRTEXP - SPROUTE EXPLAIN FILE Reference: Cases 01952689,01944648 Symptom: Customer installed an updated version of SKELB that included SCR3593. Based on the existing PRADD statements in PRECMD file, the changes implemented in SCR3593 caused MasterCard acquired transactions (Card beginning with "50") on POS terminals to be routed to BNET instead of MDS at this customer site. Problem: Conflicting requirements for the standard prefix algorithms created routing issues for some customers in certain regions of the world. SCR3593 was implemented in January of 2013 and has been installed and utilized as part of the standard PRADD and SPROUTE routing logic at multiple customer sites with no issues. This being the case, the logic added by SCR 3593 can not be simply removed. Change: Changes have been implemented in SKELB to make the SPROUTE^LOOKUP logic more extensible. With these changes, different versions of the logic can be linked into SKELB allowing the customer to choose which version they want to utilize (in the most current version of SKELB). A new module ( SPRTvv ) has been created which will be versioned and released on the XPNET subvol along with a bind file ( SPRTvvB ) and obey file ( SPRTvvBC ) to link the SPRT module into SKELB replacing the default sproute lookup logic. By default, the SKELB sproute^lookup logic will contain the most current supported prefix algorithm - requiring no customer action to implement after the updated SKELB has been installed (i.e. no changes to how this has been handled in the past). However, going forward the previous logic in SPROUTE LOOKUP will be saved in a version of SPRT and released as a separate module along with the updated SKELB, allowing a customer to quickly implement a previous version of SPROUTE LOOKUP (in the most current version of SKELB) if desired. This will also allow different algorithms to be incorporated into the sproute lookup logic without requiring a CSM (not supported in XPNET) or multiple versions of SKELB. This will also not affect customers unless they want to use it. A new edit file (SPRTEXP) will also be released which will explain the logic/differences in each version of SPRT to aid the customer to determine which SPRTvv module to bind into SKELB. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB and listed SPRT files on the XPNET subvol. Examine the SPRTEXP file to determine which version of SPRTvv to link into SKELB. Obey the SPRTvvBC to build the updated version of SKELBvv. Rename SKELB out of the way and then rename SKELBvv to SKELB. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file otherwise accelerate SKELB as shown in the OCASKELB. Dependencies: In order to utilize the SPRT module, the version of SKELB installed must be equal or newer than the ones listed in this SCR. SCR #3651 NCPCOM - rel3^ver1^ncpc26^20150407 07-APR-14 - rel3^ver1^ncpl24^20150407 SVNCS - rel3^ver1^sncs22^20150407 - rel3^ver1^ncpl24^20150407 NCPCOM - rel3^ver2^ncpc05^20150407 - rel3^ver2^ncpl05^20150407 SVNCS - rel3^ver2^sncs04^20150407 - rel3^ver2^ncpl05^20150407 Reference: 1949785 Symptom: NCPCOM abends on CONTROL DEST command. When inputting DETAIL command to see what is queuing on #DIAG-DEST, NCPCOM will abend. NCPCOM> CONTROL DEST .#DIAG-DEST, QVIEW DETAIL Problem: In proc np^format^qview^resp^text^ascii and ^hex of NCPLxxTS the following equation had the incorrect field being used to establish the address of the text that was going to be displayed. The pointer ended up being over 3000 bytes off in the message. Change: In proc np^format^qview^resp^text^ascii and ^hex of NCPLxxTS @mtptr := ( @mtp - $udbl( mtp^ofst ) - $dbl( msgtptr )) + $dbl( mofst ); it should have been: @mtptr := ( @mtp - $udbl( mtofst ) - $dbl( msgtptr )) + $dbl( mofst ); Implementation: Install the new NCPCOM, SVNCS object. Testing Considerations: This can be tested by delivering messages to a process that has been stopped. This will allow the #DIAG-DEST que to build up. Then execute the following command: CONTROL DEST .#DIAG-DEST, QVIEW DETAIL Expected Result: When executing, CONTROL DEST .#DIAG-DEST, QVIEW DETAIL, a person should be able to hit enter at the MORE prompt until the all DIAG-DEST records appear and the message below appears: "Control Dest \..#DIAG-DEST qview completed." Dependencies: None SCR #3662 SVNCPI - rel3^ver1^rel21^20150917 17-Sept-15 - rel3^ver1^ncp18^20150917 Reference: Case 02007592 Symptom: After an undetermined time and number of commands from NCPCOM, SVNCPI returned the following response for every command: Node \SYSTEM.P1-NODE status failed, incomptibl versn, NCP versn: X3.105 Versions of code involved are: Network - REL3^VER1^BASE^REL29^20110624 SVNCS - REL3^VER1^SNCS17^20110516 SVNCPI - REL3^VER1^REL18^20110516 Problem: The internal RN table in SVNCPI had field RN^VSN ( Resource Node Version ) set to zeros which caused every command after that to be incompatible. Change: After much testing, the issue could not be reproduced. A change was made so that if the condition occurs again, SVNCPI will stop itself so that it can be re-started on the next command which should reset the version. Implementation: Move in the new SVNCPI, from Pathcom, FREEZE and STOP all server ncpi processes. Stop the ppd name from the TACL prompt. From Pathcom THAW all server processes. Dependencies: XPNET 3.1. SCR #3663 NCPCOM - rel3^ver1^ncpc27^20151016 10-OCT-15 - rel3^ver1^ncpl25^20151016 SVNCS - rel3^ver1^sncs23^20151016 - rel3^ver1^ncpl25^20151016 NCPCOM - rel3^ver2^ncpc05^20150407 - rel3^ver2^ncpl05^20150407 SVNCS - rel3^ver2^sncs04^20150407 - rel3^ver2^ncpl05^20150407 Reference: 2089217 Symptom: NCPCOM abends on CONTROL DEST command. When inputting DETAIL command to see what is queuing on #DIAG-DEST, NCPCOM will abend. NCPCOM> CONTROL DEST .#DIAG-DEST, QVIEW DETAIL Problem: In proc np^format^qview^resp^text^ascii and ^hex of NCPLxxTS the following equation was changed back to it's orignal form. The pointers for the message text were not being checked correctly. this caused this program to produce an abend because the pointers were not being loaded correctly and the last byte displayed on the screen was not being carried over correctly as a starting point to display the next chunk of data in the message until the entire message was supposed to be displayed. Change: In proc np^format^qview^resp^text^ascii and ^hex of NCPLxxTS the equation was changed from: @mtptr := ( @mtp - $udbl( mtofst ) - $dbl( msgtptr )) + $dbl( mofst ); to: @mtptr := ( @mtp - $udbl( mtp^ofst ) - $dbl( msgtptr )) + $dbl( mofst ); Plus there was some checks after the performing of these 2 procs and it was changed to this: if (qview^cb.rqst^txt^lgth = -1) or (qview^cb.rqst^txt^lgth = qview^cb.last^displayed.txt^lgth^so^far) or (lgth^txt^in^this^msg = qview^cb.last^displayed.txt^lgth^so^far) or (qview^cb.last^displayed.ofst = ncp^resp^qview.single^msg.full^msg^lgth - 1) or (qview^cb.last^displayed.ofst > ncp^resp^qview.single^msg.full^msg^lgth) then ! done with this msg Implementation: Install the new NCPCOM, SVNCS object. Testing Considerations: This can be tested by delivering messages to a process that has been stopped. This will allow the #DIAG-DEST que to build up. Then execute the following command: CONTROL DEST .#DIAG-DEST, QVIEW DETAIL Expected Result: When executing, CONTROL DEST .#DIAG-DEST, QVIEW DETAIL, a person should be able to hit enter at the MORE prompt until the all DIAG-DEST records appear and the message below appears: "Control Dest \..#DIAG-DEST qview completed." Dependencies: None SCR #3671 XNCGEN - REL3_VER1_XNCG10_20160315 - REL3_VER2_XNCG01_20160315 - REL3_VER3_XNCG01_20160315 15-MAR-16 Reference: Case #2222442 Symptom: The OUTPUT produced by the XNCGEN program is not putting in spaces before the tilde (~) and the output looks like it is run together. For example: | | ARG [-JavaVMArgs2 -Xss1m -Xms96m -Xmx128m -XX:MaxPermSize=96m-Djav a.util.logging.config.file=/usr/bofa/aci1/WebATM/conf/logging.pr Problem: XNCGen reads the XML file in in 8192 byte chunks. It then parses that chunk. If the last byte read in is the last non space character before a ~, XNCGen will add a space to ensure a space between the next line (ARG) added to the ARG list. Change: Changed code to read the entire XML file and pass it to the parser routines. Implementation: Install new XNCGEN object file. Dependencies: None. SCR #3682 CTS - REL3^VER1^CTS13^20160729 29-JUL-16 - REL3^VER2^CTS01^20160729 - REL3^VER3^CTS01^20160729 - REL3^VER4^CTS00^20171230 Reference: 2291915 Symptom: A CTS line/station had a large queue and was in the process of coming down. It was failing the queued messages to the originator of the messages. At the time of the ZZSA the originator was a process that was in the NOM state so extra time was being taken to process for that. Eventually our "loop" timer expired and we abended. Problem: Our "loop" timer value wasn't large enough to allow for the extra processing time needed. Change: I added another SETLOOPTIMER call just before we fail messages from a CTS line/station queue to give us extra time. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: None. SCR #3687 SVNCS - rel3^ver1^sncs24^20161228 28-DEC-16 SVNCS - rel3^ver2^sncs07^20170117 SVNCS - rel3^ver3^sncs02^20170116 $DATA01.S31NCS.NCS05 POBJ - T3270-N24NCS (D30) 30 DEC 2016 09:58:10 - T3270-NCS (D30) 30 DEC 2016 09:57:43 - T6520-N24NCS (D30) 30 DEC 2016 09:57:56 - T6520-NCS (D30) 30 DEC 2016 09:57:30 $DATA01.S32NCS.NCS03 POBJ - T3270-N24NCS (D42) 17 JAN 2017 13:45:47 - T3270-NCS (D42) 17 JAN 2017 13:45:20 - T6520-N24NCS (D42) 17 JAN 2017 13:45:34 - T6520-NCS (D42) 17 JAN 2017 13:45:06 $DATA01.S33NCS.NCS01 POBJ - T3270-N24NCS (D42) 19 JAN 2017 09:34:57 - T3270-NCS (D42) 19 JAN 2017 09:34:38 - T6520-N24NCS (D42) 19 JAN 2017 09:34:47 - T6520-NCS (D42) 19 JAN 2017 09:34:26 Reference: 2428075 Symptom: When executing the DELIVER command, on the response the display is offset: Process \K9.P1J^NODE.P1J^DEST0 deliver complete. Process \K9.P1J^NODE.P1J^DEST1 deliver complete. Process \K9.P1J^NODE.P1J^DEST10 deliver complete. Process \K9.P1J^NODE.P1J^DEST11 deliver complete. Process \K9.P1J^NODE.P1J^DEST12 deliver complete. Process \K9.P1J^NODE.P1J^DEST13 deliver complete. Process \K9.P1J^NODE.P1J^DEST14 deliver complete. Also the wildcarded STATUS STATION and NODE command doesn't fill the screen entries causing the operator to hit F4 more times than necessary to see all station entries. Problem: The NCS requester wasn't incrementing a pointer properly when displaying the DELIVER responses. The NCS server had set the max responses in it's reply to 15 even though it was replying with fewer entries than that which caused the requester to think it had a full screen. Change: Modified the requester to increment the pointer properly and modified the server to use the actual number of entries for the max responses field. Implementation: Install updated SVNCS on the XPNET subvol. SCUP COPY the new NCS requestor(s) to the XPNET POBJ file. Dependencies: None SCR #3688 BASE - REL3^VER3^AUD01^20170113 13-JAN-17 - REL3^VER3^BASE^REL02^20170113 BASE - REL3^VER2^AUD01^20170113 - REL3^VER2^BASE^REL08^20170113 BASE - REL3^VER1^AUD07^20170113 - REL3^VER1^BASE^REL37^20170113 Reference: Case #02500701 Symptom: XPNET is not closing the audit file once its full leading to all 3 audit files being kept open by XPNET. Problem: When the final block of data is written to the audit file, there is logic to close the current file, zero the file number out and then re-open file temporarily to write the last block/EOF marker waited. If this fails for any reason, the logic calls an entry point and bypasses the code to close the temporary file number and thus it remains open as an orphaned file. This does not create any problems until AUDITA, AUDITB and AUDITC all become full. Normally when the AUDITC file becomes full, the node will roll down and re-open AUDITA, reset the EOF to 0 and start over writing audit records to it. However, in this case, the open will fail ( because the node still has it open exclusively ) 17-01-13;13:50:57.788 \SYS.$P1AN ACI.XPNET.3100 6223 File $DATA01.P1ANAUD.AUDITA, open error 12 (file in use) When this occurs and it can't open any of the files configured ( AUDITA, AUDITB, AUDITC ) then the XPNET node will disable auditing ( programmatically issuing an ALTER NODE , AUDIT OFF command ) 17-01-13;13:50:35.720 \SYS.$P1AN ACI.XPNET.3100 6138 Fatal auditing error, auditing is stopped. If AUDERROR is CONTINUE - then the node will continue processing (without auditing). If AUDERROR is STOP, the node will ABEND. If auditing is disabled, You can ALTER NODE , AUDITA (same for AUDITB and AUDITC ) then ALTER NODE , AUDIT ON and the node will then start auditing again (until all three files become full again) If you ALTER NODE , AUDITA:B:C before the last file becomes full, it will continue auditing ( leaving the stale files open ). Until this fix is installed, the only way to close these "stale" files will be to STOP the XPNET node. Change: Added logic to insure that the temporary file is properly closed in all cases. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3691 BASE - REL3^VER1^BASE^REL38^20170213 13-FEB-17 - REL3^VER1^ONCF^ONCF06^20170213 BASE - REL3^VER2^BASE^REL09^20170213 - REL3^VER2^ONCF^ONCF01^20170213 BASE - REL3^VER3^BASE^REL03^20170213 - REL3^VER3^ONCF^ONCF01^20170213 Reference: Case #2508827 Symptom: The logic to support setting the priority on messages sent via a DELIVER Command was not working correctly, preventing the DELIVER message from being pushed to the front of the destinations object queue. Problem: During XPNET 3.1 development RPE I448 to support the addition of the MSGPRIORITY NODE attribute, new logic was added to set the msg.priority on inbound DELIVER messages. This overrode the logic added in SVNCPI for SCR 2873 to set msg.priority based on PARAM "DELIVER-PRIORITY ", preventing the ability utilize priority queuing for DELIVER messages. Change: Added additional logic to check msg.priority on inbound DELIVER messages. If the value is not equal to zero then PARAM DELIVER-PRIORITY is in use, so leave it alone. If msg.priority = 0 then use NODE MSGPRIORITY to set its value. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3694 NCPCOM - rel3^ver1^ncpc29^20170317 17-MAR-17 NCPCOM - rel3^ver2^ncpc11^20170317 NCPCOM - rel3^ver3^ncpc07^20170317 Reference: Case #02514679 Symptom: NCPCOM abends when user password entered is too long. This can also result in severe impacts to the EMS log file and CPU utilization. Problem: There where two code locations where the password was being loaded into to an internal data structure that did not validate its length. If the length of the password was greater than 16 bytes, adjacent fields where corrupted causing unpredictable results. For example: NCP \SYS1.P1A^NODE.* logon failed, serverclass unknown. NCP \SYS1.P1B^NODE.* logon failed, serverclass unknown. NCP \SYS1.P1C^NODE.* logon failed, serverclass unknown. NCP \SYS1.P1D^NODE.* logon failed, serverclass unknown. NCP P1E^NODE. logon failed, unkn inv hdr reason. Node \SYS1.P1I^NODE command failed, invalid command. Node \SYS1.P1I^NODE command failed, invalid command. Node \SYS1.P1I^NODE command failed, invalid command. Change: Added logic to insure that no more than 16 bytes of the password input is moved to the internal data structure. Implementation: Install the updated NCPCOM module on the XPNET subvol. Dependencies: none SCR #3698 BASE - REL3^VER1^BASE^REL39^20170407 07-APR-17 - REL3^VER1^PROC17^20170407 BASE - REL3^VER2^BASE^REL10^20170407 - REL3^VER2^PROC02^20170407 BASE - REL3^VER3^BASE^REL05^20170407 - REL3^VER3^PROC01^20170407 Reference: Case #02540216 Symptom: In some cases during initialization application processes were not passed the correct hometerm information in the standard in and standard out fields of the NSK startup message. This could cause the application to open multiple hometerms. Problem: SCR 3118 did not work as intended under certain configurations. If the process PPD was not fully qualified with a system name (i.e. \SYS.$PPD), then the hometerm of the XPNET node was passed in the NSK startup message, ignoring the configured HOMETERM attribute of the process. Change: Changed the logic that builds the NSK standard startup message to correctly format and pass the process hometerm (if configured) in the standard in and standard out fields. If the process hometerm is blanks, the hometerm of the XPNET node will continue to be passed. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3715 3.3 POBJ - T3270-NCSS (D42) 27 SEP 2017 09:43:12 27-SEP-17 - T6520-NCSS (D42) 27 SEP 2017 09:43:22 - T3270-N24NCSS (D42) 27 SEP 2017 09:35:32 - T6520-N24NCSS (D42) 27 SEP 2017 09:35:40 3.2 POBJ - T3270-NCSS (D42) 27 SEP 2017 10:31:10 - T6520-NCSS (D42) 27 SEP 2017 10:31:19 - T3270-N24NCSS (D42) 27 SEP 2017 09:55:20 - T6520-N24NCSS (D42) 27 SEP 2017 09:55:29 3.1 POBJ - T3270-NCSS (D30) 27 SEP 2017 10:25:03 - T6520-NCSS (D30) 27 SEP 2017 10:25:13 - T3270-N24NCSS (D30) 27 SEP 2017 10:16:01 - T6520-N24NCSS (D30) 27 SEP 2017 10:16:10 Reference: Case #02634299 Symptom: XPNET NCSS requestor does not allow zeros for account expiration date field as it is documented. Problem: SCR 3585 was not coded correctly and no longer allowed a value of all zeroes in the expiration date. Change: Fixed the validation logic added by SCR 3585 to allow the expiration date to be all zeroes. Implementation: SCUP COPY the new NCSS requestor(s) to the XPNET POBJ file. Dependencies: none SCR #3709 SKELB - REL3^VER1^SUTL25^20171004 04-OCT-17 SKELLIST SKELB - REL3^VER2^SUTL04^20171004 SKELLIST SKELB - REL3^VER3^SUTL01^20171004 SKELLIST Reference: #02575212 Symptom: An application process trying to log a message using a PCI LMCF abends with a trap 2 (arithmetic overflow ) and the stack looks like this: 0 TAL #GGS_OS_STOP.#834(GUARD) + %122I 1 TAL #PROCESS_STOP_.#10275(ASYSTE) + %121I 2 TAL #TRAP^DUMP.#1191(DLIB05TS) + %10I 3 TAL #LOGMESSAGE.#8208(SUTL19TS) 4 TAL #LOG^MESSAGE^.#10027(SUTL19TS) 5 TAL #CAA^STM^0200^TO^SEM^RQST.#29971(SAAS) 6 TAL #ADA^STM^0200^REQUEST.#21498(SAAS) + %4I 7 TAL #AD^STM^^INPUT^FROM^PROCESS.#21356(SAAS) + %5I 8 TAL #SAA^A0^40.#5078(SAAS) + %4I Problem: While parsing the PCI LMCF record for the directive field, it's position on the stack caused the trap 2 because of the use of signed arithmetic. Change: Modified the signed arithmetic to un-signed arithmetic. Implementation: Since SKELB is run aa user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None SCR #3727 SVNCPI - REL3^VER1^REL22^20171201 08-DEC-17 - REL3^VER1^NCP19^20171201 - REL3^VER1^OBJ14^20171201 - REL3^VER1^RN11^20171201 SVNCPI - REL3^VER2^REL09^20171201 - REL3^VER2^NCP08^20171201 - REL3^VER2^OBJ09^20171201 - REL3^VER2^RN05^20171201 SVNCPI - REL3^VER3^REL07^20171201 - REL3^VER3^NCP06^20171201 - REL3^VER3^OBJ06^20171201 - REL3^VER3^RN04^20171201 Reference: Case #02670838 Symptom: Customer had a higher than expected transaction volume hit the system, which caused queuing and invoked NOM on the interface to VISA. They then attempted to issue DELIVER PRO command from NCPCOM, that message queued up behind everything else and went into the NOM file. Problem: Customer did not have PARAM DELIVER-PRIORITY configured to set the msg^priority on the DELIVER message and there was no way to set the NOM override flag for DELIVER messages. Change: Added a new parameter "DELIVER-NOMOVERRIDE ON/OFF" for SVNCPI to provide the ability to set the DELIVER msg^nom^override flag in the message header. By default, all DELIVER messages have a msg^nom^override set to 0. If this parameter is specified it will apply to all deliver commands(PROCESS, STATION & DEST) on that node. Implementation: Install new SVNCPI object file. Edit the pathconf and add SET SERVER PARAM DELIVER-NOMOVERRIDE to each SERVER-NCPI-?? definition you want this to apply to. Stop all the NCPI servers from TACL. Shutdown the pathway system and obey PATHCOLD. Dependencies: None SCR #3730 SVNCS - rel3^ver1^sncs25^20180110 10-JAN-18 SVNCS - rel3^ver2^sncs10^20180110 SVNCS - rel3^ver3^sncs06^20171230 SVNCS - rel3^ver4^sncs01^20180110 Reference: Case #02635374 Symptom: When executing a STATUS STATION *, DETAIL or STATUS NODE *, DETAIL command from NCS, an invalid subscript error occurs (termination status 00003, termination substatus 00000) and exits the screen. Problem: The logic added in SCR 3687 to insure the wildcard STATUS STATION * and STATUS NODE * command fills the screen did not account for the "DETAIL" modifier. This caused the NCS requestor to send another request for additional data which then created an invalid subscript. Change: Added code to check to see if the "DETAIL" modifier was specified before invoking the logic added by SCR 3687. Implementation: Install updated SVNCS on the XPNET subvol. Freeze, stop, stop, thaw SERVER-NCS. Dependencies: None SCR #3748 PWS - rel3^ver0^pws07^181129 29-NOV-18 PATHTPLS - $data01.n30pws.pws03ps PATHTPLO - $data01.n30pws.pws03po Reference: 2793513 Symptom: The client sends a message to PWS which is sent to XPNET. The client gets a zero length reply and the response is queued at the XPNET station. Problem: The client is using the new SERVERCLASS_SENDL_ call. The maximum reply size parameter is set to a value larger than 32,767. PWS uses a signed integer for the parameter which causes the maximum reply size value in PWS to be a negative number. PWS thinks the client is asking for a zero length response. PWS replies immediately with a zero length response and doesn't read the response from XPNET. Change: Altered PWS to determine that the maximum reply size is invalid. If invalid, PWS replies to the client with an error 21 ( illegal count specified ) and generates event message 1341 indicating that the maximum reply count is invalid. Implementation: Restore the PATHTPLS and PATHTPLO files to the XPNET subvolume. Remake the XPNET templates using SCRIBE.TMPLMAKE, and then remake all EMS templates using the SCRIBE.GOINST macro. Install the new PWS module, Stop and restart the PWS process. Dependencies: None. Code Review: CR-XPNET-52 SCR #3749 SKELB - REL3^VER1^SUTL26^20181228 28-DEC-18 SKELLIST - $DATA01.N31SUTL.SUTL26TL SPRT01 - REL3^VER1^SPRT01^20181228 SPRT01B - SPROUTE 01 Bind File SPRT01BC - SPROUTE 01 Bind Obey File SPRTEXP - SPROUTE 01 Spooler Listing File Reference: case #2833509 Symptom: New Customer IIN ranges need to be added to skel and sproute per mandate Problem: New customer IIN ranges need to be added for sproute mapping. Change: Changes have been implemented in SKELB and in the Sprt** modules to add the new IIN ranges for the customer. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB and listed SPRT files on the XPNET subvol. Examine the SPRTEXP file to determine which version of SPRTvv to link into SKELB. Obey the SPRTvvBC to build the updated version of SKELBvv. Rename SKELB out of the way and then rename SKELBvv to SKELB. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file otherwise accelerate SKELB as shown in the OCASKELB. Dependencies: In order to utilize the SPRT module, the version of SKELB installed must be equal or newer than the ones listed in this SCR. Code Review: CR-XPNET-053 SCR #3760 NCPCOM - REL3^VER1^NCPC30^20190503 06-MAY-19 REL3^VER1^NCPL27^20190503 NCPCOM - REL3^VER2^NCPC15^20190503 REL3^VER2^NCPL14^20190503 NCPCOM - REL3^VER3^NCPC12^20190503 REL3^VER3^NCPL11^20190503 NCPCOM - REL3^VER4^NCPC03^20190503 REL3^VER4^NCPL04^20190503 Reference: Cases 2871369 and 2881007 Symptom: When obeying an obeyform file attempting to add a device, results are unpredictable following a SET statement containing MACRO and the device is not added. Problem: An uninitialized pointer could cause random issues. Change: Properly initialized the pointer. Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.1, 3.2, 3.3, 3.4 Code Review: CR-XPNET-66 SCR #3764 OCANCPI - $DATA01.S34NCPI.OCA01AS 23-MAY-19 OXANCPI - $DATA01.S34NCPI.OXA01AS OCANCPI - $DATA01.S33NCPI.OCA01AS OXANCPI - $DATA01.S33NCPI.OXA01AS OCANCPI - $DATA01.S32NCPI.OCA02AS OCANCPI - $DATA01.S31NCPI.OCA01AS Reference: Case #02902380 Symptom: SVNCPI object is being accelerated with OCAX. OCAX/out $S.#oxa.SVNCPI, name / SVNCPI, output_file SVNCPIA, obey ZZoxa04 *** ERROR *** OCAX failed with completion code 1 See $S.#oxa.SVNCPI for error information. OCAX - T0892L01 - (Apr 8 2017 08:36:06) Copyright 2017 Hewlett Packard Enterprise Development LP. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 2. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 3. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 4. Problem: New warnings from the acceleration of SVNCPI. Change: Updated the OCANCPI and OXANCPI to remove warnings. OXANCPI #append oxa_cmds INHERITSR2 SEC^GUARD^VERIFY^CPC #append oxa_cmds INHERITSR3 SEC^GUARD^VERIFY^CPC #append oxa_cmds INHERITSR4 SEC^GUARD^VERIFY^CPC OCANCPI #append oca_cmds INHERITSR2 SEC^GUARD^VERIFY^CPC #append oca_cmds INHERITSR3 SEC^GUARD^VERIFY^CPC #append oca_cmds INHERITSR4 SEC^GUARD^VERIFY^CPC Implementation: Install updated OCANCPI and OXANCPI and obey the macro. Dependencies: none Code Review: CR-XPNET-69 SCR #3772 SUTL - rel3^ver4^sutl02^20190927 27-SEP-19 SUTL - rel3^ver3^sutl03^20190927 SUTL - rel3^ver2^sutl06^20190927 SUTL - rel3^ver1^sutl27^20190927 Reference: Case #02959487 Symptom: VISA abended for unknown reason. Problem: The log^messageX code is doing signed moves which causes an arithemetic overflow when the data pointer passed in by the calling routine is over 32735 and under 32763. Change: Modified the SUTL log^messageX code to move the pointer using unsigned moves. Implementation: Since SKELB is run aa user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: none Code Review: CR-XPNET-xxx SCR #3777 SKELB - REL3^VER1^SUTL28^20200320 20-mar-20 SKELLIST - $DATA01.N31SUTL.SUTL28TL SPRT01 - REL3^VER1^SPRT0x^20200320 SPRT01B - SPROUTE 0x Bind Fileisting File SPRT01BC - SPROUTE 0x Bind Obey File SPRTEXP - SPROUTE 0x Spooler Listing File Reference: case:na Symptom: New Customer IIN ranges need to be added to skel and sproute per mandate Problem: New customer IIN ranges need to be added for sproute mapping. Change: Changes have been implemented in SKELB and in the Sprt** modules to add the new IIN ranges for the customer. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB and listed SPRT files on the XPNET subvol. Examine the SPRTEXP file to determine which version of SPRTvv to link into SKELB. Obey the SPRTvvBC to build the updated version of SKELBvv. Rename SKELB out of the way and then rename SKELBvv to SKELB. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file otherwise accelerate SKELB as shown in the OCASKELB. Dependencies: In order to utilize the SPRT module, the version of SKELB installed must be equal or newer than the ones listed in this SCR. Code Review: CR-XPNET-090